CVE-2026-67213

What it actually does

nanoid before 5.1.6 can enter an infinite loop when the customAlphabet or customRandom API is called with an identifier size of 0. If an application allows an unauthenticated remote user to influence that size parameter, a single crafted request can cause the Node.js event loop or worker handling the request to spin indefinitely, consuming CPU and preventing normal request processing. The impact is denial of service; the flaw does not directly provide code execution, data disclosure, or privilege escalation.

Why it matters to the business

Applications that expose attacker-controlled Nano ID generation parameters may become slow or unavailable, causing failed transactions, degraded APIs, queue backlogs, timeouts, and increased infrastructure costs from stuck or saturated Node.js processes. Although this CVE is not currently in CISA KEV and has no reported exploit maturity, it is only 13 days old and is easy to trigger where vulnerable input handling exists, so internet-facing services and high-volume APIs should treat remediation as time-sensitive.

How an attack unfolds

An attacker first identifies an application function that generates Nano ID values using customAlphabet or customRandom and accepts a user-controllable size, length, count, or similar parameter. The attacker then sends a request with that parameter set to 0. In vulnerable nanoid versions before 5.1.6, the library enters a generation loop whose exit condition is never satisfied. The affected request handler, worker, or process spins indefinitely, consuming CPU and tying up execution capacity. Repeating the request or targeting multiple endpoints can exhaust available workers, increase latency, and cause partial or full service outage.

How to fix it

Upgrade nanoid to version 5.1.6 or later anywhere it is used directly or transitively. If package managers resolve nanoid transitively, refresh lockfiles and verify the resolved version is no longer below 5.1.6. In addition, validate all inputs used as Nano ID sizes: require a positive integer, enforce a reasonable upper bound, reject 0, reject negative values, and reject non-numeric values before calling customAlphabet or customRandom. For defense in depth, add request timeouts, worker isolation, rate limiting, circuit breakers, and process supervision so a stuck request cannot indefinitely consume service capacity. If an immediate upgrade is not possible, patch application code to prevent size 0 from reaching nanoid and consider pinning or overriding transitive dependency resolution to nanoid 5.1.6 or later.

How to confirm the fix worked

Confirm all deployed builds resolve nanoid to 5.1.6 or later using dependency manifests, lockfiles, software composition analysis, or package manager commands such as npm ls nanoid, pnpm why nanoid, or yarn why nanoid. Review code paths that call customAlphabet or customRandom and verify the size argument is validated as a positive integer before invocation. Add or run unit tests that pass size 0 and confirm the application rejects the request quickly rather than hanging. In a controlled non-production environment, test affected endpoints with size, length, or count set to 0 and verify the request receives a validation error and CPU does not spike or remain saturated.

Typical attack path

1. Find an application endpoint or API workflow that creates Nano ID values from user-influenced input.
2. Determine whether the identifier length or size parameter can be set to 0 or coerced to 0.
3. Send a crafted request that causes customAlphabet or customRandom to be invoked with size 0.
4. Cause the vulnerable Node.js thread or worker to enter an infinite loop and consume CPU.
5. Repeat requests or distribute them across instances to degrade availability or trigger service outage.

How to detect it

Look for signs of denial-of-service rather than traditional post-compromise artifacts. Relevant sources include application access logs, API gateway logs, WAF logs, Node.js process metrics, container or orchestrator events, APM traces, and dependency inventories. Search for requests with parameters or JSON fields such as size, length, idLength, nanoidLength, count, or limit set to 0, especially immediately before CPU saturation, request timeouts, event-loop lag, pod/container restarts, or autoscaling events. Review stack traces, debug logs, and APM spans for calls to nanoid customAlphabet or customRandom that never complete. Because the vulnerability causes a hang and not code execution, there may be no file, process, registry, or persistence artifact; absence of such artifacts does not rule out exploitation.

• size=0
• length=0
• idLength=0
• nanoidLength=0
• "size":0
• "length":0
• "idLength":0
• "nanoidLength":0
• customAlphabet
• customRandom
• node_modules/nanoid/package.json
• "nanoid":"5.1.5"
• "nanoid": "5.1.5"

What your security team should do

• Inventory all applications and services using nanoid, including transitive dependency usage in Node.js applications.
• Prioritize internet-facing APIs, authentication/registration flows, object creation endpoints, and high-volume services where user input may influence generated ID length.
• Upgrade nanoid to 5.1.6 or later and rebuild/redeploy affected services from clean dependency lockfiles.
• Add input validation to reject identifier sizes of 0 and enforce safe lower and upper bounds before calling Nano ID generation functions.
• Search application logs and performance telemetry for recent request patterns containing size=0, length=0, or count=0 correlated with CPU spikes, request timeouts, worker restarts, or service degradation.
• Add temporary WAF/API-gateway rules or schema validation to block requests that set ID generation size-like parameters to 0 for endpoints known to use Nano ID.
• Monitor dependency advisories and EPSS/KEV status for changes because exploitation may increase after public disclosure.