CVE-2026-3449

What it actually does

@tootallnate/once versions before 3.0.1 mishandle promise resolution when the AbortSignal option is used. If the signal is aborted, the promise can remain permanently pending instead of resolving or rejecting. Code that awaits the promise, chains .then(), or depends on completion for cleanup can hang indefinitely, causing control-flow leakage, stalled asynchronous operations, blocked workers, and reduced application availability. The flaw is availability-focused; it does not directly provide code execution, data disclosure, or integrity modification.

Why it matters to the business

Applications that depend on vulnerable versions may experience degraded reliability when cancellation or timeout paths are exercised. In affected request, job, proxy, or worker flows, operations can hang rather than fail cleanly, consuming capacity and potentially causing slow responses, request backlogs, or worker exhaustion. The public exploitation signal is currently low: EPSS is 0.00112 with a flat 30-day trend, there is no known CISA KEV listing, no ransomware association, and no mature public exploit noted. Even so, because this is a dependency-level availability issue, the practical risk depends on how widely the package is included in production services and whether abortable operations are reachable by users or automated workloads.

How an attack unfolds

An attacker first needs a reachable application path that uses a vulnerable @tootallnate/once version with the AbortSignal option. They then cause the relevant operation to be aborted, commonly by triggering cancellation, timeout, disconnected-request handling, or other abort logic in the application. Because the vulnerable package leaves the associated promise pending, the application code waiting for that promise may never continue to cleanup, error handling, or resource release logic. Repeating this against reachable paths can accumulate hung operations, blocked workers, or exhausted concurrency slots, resulting in degraded service availability. In many deployments this is not directly exploitable from the network unless the application exposes an abortable workflow to untrusted users; otherwise, exploitation may require local or application-level access.

How to fix it

Upgrade @tootallnate/once to version 3.0.1 or later wherever it appears in direct or transitive dependencies. Regenerate and commit lockfiles after the upgrade, then rebuild and redeploy affected applications. If the package is pulled in transitively, update the parent dependency that brings it in, or use package-manager override/resolution controls to force @tootallnate/once >= 3.0.1 until upstream dependencies are updated. As a temporary mitigation, review code paths using AbortSignal with this package and add independent timeout handling, rejection paths, cleanup guards, and worker/request limits so aborted operations cannot remain indefinitely pending. Monitor capacity, queue depth, and request timeout metrics after deployment to confirm normal behavior.

How to confirm the fix worked

Confirm dependency state using software composition analysis and package-manager commands such as npm ls @tootallnate/once, yarn why @tootallnate/once, or pnpm why @tootallnate/once. Inspect package-lock.json, yarn.lock, pnpm-lock.yaml, and deployed SBOMs to ensure no resolved @tootallnate/once version is below 3.0.1. Add or run a regression test that creates an operation using AbortSignal, aborts the signal, and verifies the waiting promise rejects or otherwise completes within a bounded timeout rather than remaining pending. Validate deployed artifacts, containers, and serverless bundles rather than only source repositories, because vulnerable transitive dependencies may remain in built images or cached layers.

Typical attack path

1. Identify an application or service that includes @tootallnate/once before version 3.0.1.
2. Find a code path where the package is used with an AbortSignal, such as cancellation, timeout, stream, socket, request, or job-processing logic.
3. Trigger the operation and cause the AbortSignal to abort before normal completion.
4. Rely on the vulnerable behavior where the promise remains permanently pending instead of resolving or rejecting.
5. Repeat the action to accumulate stalled asynchronous operations, blocked workers, or exhausted request/job capacity.
6. Cause user-visible service degradation, elevated latency, request timeouts, or partial denial of service.

How to detect it

There are no unique network signatures or file artifacts that prove exploitation of this dependency-level flaw. To assess prior exploitation or triggering, correlate dependency exposure with application behavior. Review application logs, API gateway logs, reverse proxy logs, worker/job logs, APM traces, and runtime metrics for abnormal increases in aborted requests, client disconnects, timeout errors, long-running requests, stalled jobs, worker saturation, queue buildup, or requests that start but never log normal completion. Focus on time windows after deployment of code containing @tootallnate/once before 3.0.1 and on endpoints or jobs that use cancellation, AbortSignal, stream handling, socket handling, or timeout logic. In Node.js observability data, look for increasing pending asynchronous operations, elevated event-loop delay, exhausted worker pools, or memory/concurrency growth without corresponding completed work. Because the vulnerability leaves promises pending, forensic evidence is usually circumstantial and behavior-based rather than tied to a distinct exploit payload.

What your security team should do

• Prioritize remediation for internet-facing, high-concurrency, job-processing, proxy, API gateway, streaming, or worker-based services that use Node.js and expose cancellation or timeout paths.
• Upgrade or override @tootallnate/once to version 3.0.1 or later across all repositories, build images, and runtime artifacts.
• Use SCA, SBOM, and lockfile scanning to identify both direct and transitive occurrences of @tootallnate/once before 3.0.1.
• Add automated CI policy to fail builds that include vulnerable versions of this package.
• Review application timeout and abort handling so cancellation paths always release resources and do not rely on unbounded awaits.
• Monitor service health indicators such as pending request counts, worker saturation, queue depth, request disconnects, and timeout rates for signs of exploitation or operational triggering.
• Because KEV, ransomware, exploit maturity, and EPSS signals are currently low, treat this as a reliability-hardening dependency update unless vulnerable code is present in business-critical or externally triggerable flows.