GHSA-xwg4-73v4-xw9w CVE-2026-73086
nanoid: Integer Overflow or Wraparound
- Severity
- 7.4 / 10
- High · CVSS 3.1
- Exploit chance (EPSS)
- 0.30%
- Chance of exploitation in the next 30 days. Higher than 22.34% of scored vulnerabilities.
- Known exploited
- No
- Not in CISA's catalog
- Weakness
- CWE-190 Integer Overflow or Wraparound
- Fix
3.3.12- Upgrade nanoid to this version or later
Description
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-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
nanoidin the same process - No special privileges or preconditions required — a single unauthenticated request is sufficient
- Affects any application that passes external input to the
sizeparameter without validation
Affected versions
npm
| Package | Vulnerable | Fixed in |
|---|---|---|
| nanoid | < 3.3.12 |
3.3.12 |
| nanoid | >= 4.0.0, < 5.1.11 |
5.1.11 |
| nanoid | < 3.3.12 |
3.3.12 |
| nanoid | >= 4.0.0, < 5.1.11 |
5.1.11 |
How to fix
Move to the fixed version or later with your package manager, update the lockfile, and run your tests. If the package only arrives through another dependency, upgrade that dependency first. If none of its releases pulls a fixed version yet, force the version with your package manager's override.
nanoid npm → 3.3.12
- npm
npm install nanoid@3.3.12- yarn
yarn add nanoid@3.3.12- pnpm
pnpm add nanoid@3.3.12
Severity breakdown
CVSS 3.1 7.4
CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:N
- Attack vector
- Network
- Attack complexity
- High
- Privileges required
- None
- User interaction
- None
- Scope
- Unchanged
- Confidentiality
- High
- Integrity
- High
- Availability
- None
Weakness
CWE-190: Integer Overflow or Wraparound
The product performs a calculation that can produce an integer overflow or wraparound when the logic assumes that the resulting value will always be larger than the original value. This occurs when an integer value is incremented to a value that is too large to store in the associated representation. When this occurs, the value may become a very small or negative number.
How to prevent it
- Requirements: Ensure that all protocols are strictly defined, such that all out-of-bounds behavior can be identified simply, and require strict conformance to the protocol.
- Requirements: Use a language that does not allow this weakness to occur or provides constructs that make this weakness easier to avoid. If possible, choose a language or compiler that performs automatic bounds checking.
- Architecture and Design: Use a vetted library or framework that does not allow this weakness to occur or provides constructs that make this weakness easier to avoid [REF-1482]. Use libraries or frameworks that make it easier to handle numbers without unexpected consequences. Examples include safe integer handling packages such as SafeInt (C++) or IntegerLib (C or C++). [REF-106]
- Implementation: Perform input validation on any numeric input by ensuring that it is within the expected range. Enforce that the input meets both the minimum and maximum requirements for the expected range. Use unsigned integers where possible. This makes it easier to perform validation for integer overflows. When signed integers are required, ensure that the range check includes minimum values as well as maximum values.
- Implementation: Understand the programming language's underlying representation and how it interacts with numeric calculation (CWE-681). Pay close attention to byte size discrepancies, precision, signed/unsigned distinctions, truncation, conversion and casting between types, "not-a-number" calculations, and how the language handles numbers that are too large or too small for its underlying representation. [REF-7] Also be careful to account for 32-bit, 64-bit, and other potential differences that may affect the numeric representation.
- Architecture and Design: For any security checks that are performed on the client side, ensure that these checks are duplicated on the server side, in order to avoid CWE-602. Attackers can bypass the client-side checks by modifying values after the checks have been performed, or by changing the client to remove the client-side checks entirely. Then, these modified values would be submitted to the server.
- Implementation: Examine compiler warnings closely and eliminate problems with potential security implications, such as signed / unsigned mismatch in memory operations, or use of uninitialized variables. Even if the weakness is rarely exploitable, a single failure may lead to the compromise of the entire system.
References
Advisories
Fixes and patches
Packages
Other links
Timeline
- Published
- Last updated by the source
- Latest EPSS score
Related advisories
| Advisory | Severity | Why it's related |
|---|---|---|
| GHSA-28wg-ghj8-5hjv nanoid: non-secure generators can loop indefinitely with negative size | High | Also affects nanoid |
| GHSA-2v37-7h3g-55p8 nanoid: custom generators can loop indefinitely when size is zero | High | Also affects nanoid |
| GHSA-mwcw-c2x4-8c55 Predictable results in nanoid generation when given non-integer values | Medium | Also affects nanoid |
| GHSA-qrpm-p2h7-hrv2 Exposure of Sensitive Information to an Unauthorized Actor in nanoid | Medium | Also affects nanoid |
| GHSA-4642-5mcj-2rqw Forge: ASN.1 OID first arc truncation in asn1.oidToDer | Low | Same weakness, CWE-190 |
| GHSA-4rm8-3hmm-39fg Pillow: Reachable undefined behavior in native integer operations, potentially leading to denial of service or logic integrity compromise | Medium | Same weakness, CWE-190 |
| GHSA-f63g-mx39-3r38 Microsoft Security Advisory CVE-2026-85363 - .NET and Visual Studio Remote Code Execution Vulnerability | High | Same weakness, CWE-190 |
| CVE-2026-97229 Integer Overflow or Wraparound in GitLab | Critical Known exploited | Same weakness, CWE-190 |
Credits: alanzabihi
MergeHarbor checks every repository's dependencies against this database, ranks what matters by exploitability and reachability, routes it to the owning team and opens the fix pull request.
Check your repos with MergeHarbor