CVE-2026-73086 in nanoid
Summary
by MITRE • 08/12/2026
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.
Be aware that VulDB is the high quality source for vulnerability data.
Analysis
by VulDB Data Team • 08/12/2026
The nanoid library represents a widely-used JavaScript implementation for generating secure, URL-friendly unique string identifiers that are essential for cryptographic security purposes including session tokens, CSRF protection, and API key generation. This vulnerability affects versions prior to 3.3.12 and 5.1.11 where the core function nanoid(size) demonstrates a critical flaw in parameter validation and type coercion handling within the index.js and index.cjs modules. The issue stems from the improper conversion of user-provided size parameters to signed 32-bit integers without proper bounds checking or overflow protection mechanisms.
The technical exploitation occurs when an attacker provides a size value of exactly 2147483648 which exceeds the maximum positive value representable by a signed 32-bit integer. This value gets coerced into -2147483648 due to two's complement representation, fundamentally altering the behavior of the internal cryptographic random number generation process. The fillPool() function that manages the process-wide cryptographically secure pseudorandom number generator poolOffset becomes corrupted when this negative size parameter is processed, leading to deterministic output patterns instead of truly random sequences.
This vulnerability directly impacts the security posture of applications relying on nanoid for generating unique identifiers by introducing a deterministic failure mode where all subsequent generated tokens become identical strings of "uuuuuuuuuuuuuuuuuuuuu". The impact extends beyond simple identifier generation to compromise core security mechanisms including session management, cross-site request forgery protection, and API key generation. From a cybersecurity perspective, this represents a severe degradation in entropy quality that aligns with CWE-129 weakness classification for improper validation of length parameters and CWE-330 weakness related to insufficient entropy in random number generation.
The operational consequences are particularly dangerous because the vulnerability persists throughout the entire application lifecycle until process restart, creating an extended window of opportunity for attackers to exploit deterministic token generation patterns. This allows for session hijacking, CSRF attacks, and API abuse where attackers can predict or reproduce security tokens that should remain unpredictable. The ATT&CK framework would categorize this under T1078 Valid Accounts and T1566 Phishing as attackers could leverage the predictable nature of these identifiers to bypass authentication mechanisms. Organizations using vulnerable versions face significant risk of credential theft, data breaches, and unauthorized system access due to the fundamental breakdown in cryptographic security guarantees provided by the library.
Mitigation requires immediate upgrade to nanoid versions 3.3.12 or 5.1.11 where proper integer bounds checking has been implemented to prevent size parameter overflow conditions. Security teams should conduct comprehensive vulnerability assessments across all systems using affected versions and implement runtime monitoring for suspicious token generation patterns. The fix addresses the core issue by ensuring that size parameters are properly validated against maximum allowed values before any cryptographic operations begin, thereby preserving the integrity of the CSPRNG pool and maintaining cryptographic security guarantees throughout the application lifecycle.