Description

nanoid is a secure, URL-friendly, unique string ID generator for JavaScript. Prior to versions 3.3.12 and 5.1.11, the nanoid(size) function in index.js and index.cjs coerces the user-influenced size parameter to a signed 32-bit integer, allowing a value of 2147483648 to become -2147483648 and corrupt the process-wide CSPRNG poolOffset in fillPool(), which causes subsequent session tokens, CSRF tokens, API keys, and unique identifiers to become the deterministic string "uuuuuuuuuuuuuuuuuuuuu" until the process restarts. This issue is fixed in versions 3.3.12 and 5.1.11.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "7.4",
  "pubDate": "2026-08-11T17:19:16.690Z",
  "pubdate": "2026-08-11T17:19:16.690Z",
  "executiveSummary": "An integer coercion vulnerability exists within the nanoid string ID generator package prior to versions 3.3.12 and 5.1.11. The flaw resides in the handling of the user-influenced size parameter within index.js and index.cjs, where input is improperly coerced into a signed 32-bit integer. This improper type conversion permits an attacker to supply a specific malicious integer value, which wraps around negatively and corrupts the process-wide cryptographic pseudorandom number generator poolOffset mechanism inside the fillPool() function. The direct consequence of this memory state corruption is that all subsequent generation routines for session tokens, CSRF tokens, API keys, and unique identifiers become completely deterministic, outputting a static repeating string value of uuuuuuuuuuuuuuuuuuuuu until the underlying Node.js process is forcibly restarted. This introduces a severe cryptographic failure and predictability risk across all consuming systems and services. Attacker capabilities involve supplying crafted size values to predictable or exposed nanoid interfaces to induce permanent state corruption without requiring advanced privileges or authentication, provided the parameter is user-influenced. Remediation requires upgrading the nanoid package to version 3.3.12, version 5.1.11, or later.",
  "technicalDetails": "The vulnerability is rooted in inadequate input validation and type coercion practices within the nanoid library. Specifically, the nanoid(size) function located in index.js and index.cjs accepts a size parameter that can be influenced by external user input. When an attacker supplies a large numeric value such as 2147483648, the internal coercion logic maps this value into a signed 32-bit integer. Due to integer overflow boundaries, 2147483648 translates directly into -2147483648.\nThis negative integer is subsequently passed into the internal fillPool() function, which manages the cryptographically secure pseudorandom number generator pool and its associated pointer, poolOffset. Because poolOffset is updated or evaluated based on this manipulated negative offset, the state logic breaks down, corrupting the global allocation tracking of the randomness buffer. Consequently, the CSPRNG fails to consume fresh entropy properly, causing the underlying random byte generation to stall or loop into a static byte sequence.\nThe attack flow proceeds as follows: 1) An attacker identifies an application endpoint or interface where the size parameter of the nanoid function can be directly or indirectly controlled. 2) The attacker submits a malicious input payload equating to 2147483648. 3) The nanoid function coerces the input into the signed 32-bit integer -2147483648. 4) The fillPool() routine processes the negative offset, resulting in the corruption of the process-wide poolOffset state. 5) All subsequent calls to generate unique identifiers across the entire Node.js process bypass true randomness generation and persistently output the deterministic string uuuuuuuuuuuuuuuuuuuuu.\nThe vulnerable components are index.js and index.cjs within nanoid versions prior to 3.3.12 and 5.1.11. The vulnerability affects all systems utilizing these vulnerable package versions where application logic exposes the size parameter to untrusted callers. No specialized authentication, high privileges, or network exposure vectors beyond application-level parameter control are required to trigger the coercion."
}