nanoid CVE-2026-67213

Exploitation requires that the target application call nanoid's customAlphabet or customRandom function and pass a size (length) argument of exactly 0 that is derived from unvalidated, attacker-controlled input; this precondition is exactly what the CVSS 4.0 AT:P metric encodes. The default nanoid() generator and any usage with a hardcoded or server-validated positive size are NOT exploitable. Limiting factors: the vulnerable custom-generator code path must be reachable by the attacker, the size parameter must flow from untrusted input without a positive-integer check, and impact is confined to availability (thread hang / DoS) with no confidentiality or integrity effect. No authentication or user interaction is required by the library itself (PR:N/UI:N), but real exposure is entirely gated by the consuming application's design.

The CVSS 4.0 base score is 8.2 (High) with vector AV:N/AC:L/AT:P/PR:N/UI:N and impact isolated to availability (VA:H; VC:N/VI:N). The AT:P (Attack Requirements: Present) metric is the crucial signal: exploitation is not universal against all deployments but requires the specific precondition that the consuming application passes an attacker-influenced size of 0 into customAlphabet/customRandom. There is no EPSS score, no KEV listing, and no confirmed public PoC in the provided data, so the real-world urgency is lower than the raw 8.2 suggests - this is a conditional, library-consumer-dependent DoS rather than a broadly weaponizable RCE. Because impact is availability-only and depends on how downstream code validates input, priority should scale with whether your application exposes an externally controllable ID-length parameter; libraries that hardcode size are effectively unaffected. Note the tension: 'PR:N/UI:N' implies trivial remote triggering, but AT:P and the description ('unvalidated, attacker-controlled size') confirm it only manifests through a particular application code path - verify your own usage before treating this as network-exploitable by default.

An application exposes an API endpoint that generates identifiers using nanoid's customAlphabet, letting the client specify the ID length. An attacker sends a request with length=0, causing the worker thread/event loop to enter an infinite loop and stop serving all other requests, producing a denial of service. No public exploit code is identified, but the trigger is trivial to craft given a vulnerable code path.