GHSA-xwg4-73v4-xw9w: Integer Overflow
Summary
An integer overflow in nanoid(size) permanently corrupts the process-wide CSPRNG pool, causing all subsequent ID generation to return the deterministic string "uuuuuuuuuuuuuuuuuuuuu". Any application that passes user-influenced values to the size parameter loses all randomness guarantees for session tokens, CSRF tokens, and unique identifiers until process restart.
Details
nanoid() at index.js:101 coerces the size parameter with size |= 0, which converts it to a signed 32-bit integer. When size >= 2^31 (e.g., 2147483648), this wraps to -2147483648.
The negative value is passed to fillPool() (index.js:15):
javascript function fillPool(bytes) { if (!pool || pool.length < bytes) { // false: pool exists, -2B < pool.length pool = Buffer.allocUnsafe(bytes POOLSIZEMULTIPLIER) crypto.getRandomValues(pool) poolOffset = 0 } else if (poolOffset + bytes > pool.length) { // false: poolOffset + (-2B) < pool.length crypto.getRandomValues(pool) poolOffset = 0 } poolOffset += bytes // poolOffset += -2147483648 → deeply negative }
Neither branch triggers, so the pool is never refreshed. poolOffset becomes ~-2.1 billion.
Subsequent nanoid() calls execute: javascript for (let i = poolOffset - size; i < poolOffset; i++) { id += scopedUrlAlphabet[pool[i] & 63] }
pool[negativeindex] returns undefined. undefined & 63 evaluates to 0. urlAlphabet[0] is 'u'. Every ID becomes "uuuuuuuuuuuuuuuuuuuuu".
The corruption is persistent — it affects all subsequent calls in the process until ~100 million calls eventually wrap poolOffset back to positive, or the process restarts.
PoC
javascript import { nanoid } from 'nanoid'
// Step 1: Normal operation console.log(nanoid()) // e.g., "V1StGXR8Z5jdHi6B-myT"
// Step 2: Trigger overflow (e.g., from an API parameter) try { nanoid(2147483648) } catch(e) {}
// Step 3: All subsequent IDs are deterministic console.log(nanoid()) // "uuuuuuuuuuuuuuuuuuuuu" console.log(nanoid()) // "uuuuuuuuuuuuuuuuuuuuu" console.log(nanoid()) // "uuuuuuuuuuuuuuuuuuuuu" // ... forever, process-wide
Run with: node --experimental-vm-modules poc.mjs
Attack scenario: Any API endpoint that accepts a user-controlled length/size parameter (URL shortener slug length, configurable token size, etc.) and passes it to nanoid(userInput).
Impact
Complete loss of ID unpredictability and uniqueness, process-wide, from a single request.
- All session IDs, CSRF tokens, API keys, and database identifiers generated after the attack are identical and predictable - An attacker can predict all tokens issued to other users, enabling session hijacking and authentication bypass - The corruption is persistent (survives across requests) and affects all consumers of nanoid in the same process - No special privileges or preconditions required — a single unauthenticated request is sufficient - Affects any application that passes external input to the size parameter without validation
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
npm/nanoidto a version that resolves this vulnerability.Fixed in 5.1.11 - Upgrade
Upgrade
npm/nanoidto a version that resolves this vulnerability.Fixed in 3.3.12 - Configuration
Ensure any user-influenced value passed as the `size` argument to `nanoid(size)` is validated/clamped so it can never reach the overflow-triggering range (the text states corruption occurs when `size >= 2^31`, e.g., `2147483648`). Reject or clamp such inputs before calling `nanoid()`.
nanoid (JavaScript/Node) usage size parameter validation = instructional - Operational
Restart the Node.js process after an integer overflow has been triggered, because the corruption is persistent and affects all subsequent `nanoid()` calls in the same process until process restart (the text describes deterministic output like "uuuuuuuuuuuuuuuuuuuuu" until restart).
Event History
Frequently Asked Questions
What input conditions can trigger the issue?
The issue is triggered when nanoid(size) receives a size value of 2^31 or greater, such as 2147483648. This is particularly relevant where an attacker can influence the size parameter.
Which generated values are at risk after exploitation?
All subsequent IDs generated by the affected process become the deterministic string "uuuuuuuuuuuuuuuuuuuuu" until the process is restarted. Session tokens, CSRF tokens, and unique identifiers generated after triggering are therefore affected.
How can I tell whether an application process has already been affected?
Check whether nanoid calls are repeatedly returning "uuuuuuuuuuuuuuuuuuuuu". Repeated output of that exact value indicates that the process-wide randomness pool has been corrupted.
What can be done if a fix cannot be applied immediately?
Do not allow user-influenced values to reach the size parameter, and reject or constrain values at or above 2147483648. If the condition has already been triggered, restart the affected process to restore the CSPRNG pool.