CVE-2024-55565

What it actually does

nanoid before 5.0.9, and affected 3.x releases before 3.3.8, does not properly validate that ID-generation length inputs are integers. If an application allows an attacker-controlled value to reach nanoid as the requested ID size, the library can generate identifiers that do not match the application’s expected length or format assumptions. The assessed impact is limited to integrity: this can undermine application logic that relies on generated IDs being consistently shaped, unique within expected parameters, or compliant with downstream validation rules; it is not assessed as directly exposing data or causing service-wide availability loss.

Why it matters to the business

Applications that use nanoid for externally influenced identifiers, tokens, invite codes, short links, object IDs, or workflow references may create IDs that violate business rules or collide with assumptions in surrounding code. In practical terms, this could lead to incorrect record association, bypass of format-based checks, broken workflows, or data consistency issues where applications trust the generated ID structure. The public exploitation signal is currently low: EPSS is 0.00679, it is not in CISA KEV, no ransomware use is indicated, and exploit maturity is listed as none; however, the issue has been public for 608 days, so dependency hygiene rather than emergency incident response is the primary driver.

How an attack unfolds

An attacker first identifies an application endpoint or workflow where a user-controllable value is used to determine the length or configuration of a Nano ID generated by nanoid. The attacker supplies a non-integer value, such as a decimal, numeric string that is not safely normalized, or another malformed numeric representation, depending on how the application parses input before passing it to nanoid. Because vulnerable nanoid versions mishandle non-integer values, the generated ID may not conform to the length or format the application expects. The attacker then attempts to use the resulting malformed or unexpected identifier in follow-on operations, such as object creation, invitation flows, link generation, reference-code assignment, or authorization-adjacent business logic. Successful exploitation depends heavily on the embedding application: the library flaw is most meaningful where application security or integrity decisions assume nanoid always returns an identifier of a strictly validated size.

How to fix it

Upgrade nanoid to a fixed release. For current 5.x usage, upgrade to nanoid 5.0.9 or later. For projects pinned to the 3.x line, upgrade to nanoid 3.3.8 or later. Source builds should include the upstream fix at commit 65a38ac63a0709c420b9de30b15511b84e87c423 or a later trusted commit. After upgrading, rebuild and redeploy applications, containers, serverless packages, and front-end bundles that include the dependency. As a defense-in-depth measure, validate all caller-supplied ID size or configuration values before invoking nanoid: require finite safe integers, enforce minimum and maximum bounds, reject decimals and strings unless explicitly parsed and validated, and avoid allowing untrusted users to choose security-sensitive identifier lengths.

How to confirm the fix worked

Confirm dependency versions from package manifests and lockfiles, including transitive dependency trees. Use package-manager commands such as `npm ls nanoid`, `pnpm why nanoid`, or `yarn why nanoid` to identify every resolved instance. Verify that all resolved versions are 5.0.9 or later, or 3.3.8 or later for projects intentionally maintained on the 3.x branch. Confirm that production artifacts were rebuilt after the dependency update, because lockfile changes alone do not protect already-built bundles or containers. Add or run unit tests that call the application’s ID-generation paths with decimal, string, negative, NaN, Infinity, null, and oversized values and assert that invalid input is rejected before reaching nanoid. For runtime exposure validation, review code paths for direct use of user input as the nanoid size argument or as the default size in custom alphabet generation.

Typical attack path

1. Find an application feature that generates Nano IDs using user-influenced input, such as requested ID length, code length, or configuration parameters.
2. Submit non-integer or malformed numeric values to the feature and observe generated identifier length, format, or downstream validation behavior.
3. Compare behavior against expected ID constraints to determine whether the application accepts, stores, or acts on malformed identifiers.
4. Use the unexpected identifier in follow-on workflows, such as object lookup, invitation redemption, short-link access, or record creation.
5. Attempt to exploit resulting business-logic inconsistencies, such as bypassing format checks, causing incorrect associations, or creating records with identifiers outside expected constraints.

How to detect it

There are no reliable universal host, network, or file indicators that prove exploitation of this library flaw, because exploitation is expressed through application-specific inputs and resulting malformed identifiers. To investigate possible prior exploitation, review application access logs, API gateway logs, WAF logs, and structured application logs for requests to ID-generation, object-creation, invite-code, short-link, token-creation, or reference-code endpoints containing decimal, negative, extremely large, non-numeric, NaN, Infinity, null, or otherwise malformed values in parameters that control size, length, limit, codeLength, idLength, tokenLength, or similar fields. Review database or application records created during suspicious request windows for identifiers with unexpected lengths, unexpected character sets, empty or truncated values, or values that violate documented ID constraints. Correlate anomalous identifier creation with authentication context, source IP, user agent, repeated probing attempts, and follow-on access to the generated identifiers. If the application logs library exceptions, also search for validation, range, or type errors near ID-generation code, although absence of errors does not rule out exploitation.

What your security team should do

• Inventory all applications and packages that depend on nanoid, including transitive dependency usage in Node.js, browser bundles, serverless functions, and container images.
• Prioritize upgrades where nanoid-generated identifiers are used in externally reachable workflows, authorization-adjacent references, invite or redemption codes, short links, object identifiers, or record keys.
• Upgrade to nanoid 5.0.9 or later, or 3.3.8 or later for projects that must remain on the 3.x line, and ensure the fix is present in deployed artifacts.
• Add input validation around every application-controlled ID length or configuration parameter: allow only finite safe integers within explicit bounds.
• Search code for calls where untrusted request parameters, body fields, query strings, headers, or configuration values are passed directly into `nanoid()` or `customAlphabet()`.
• Add regression tests for non-integer and malformed numeric inputs to prevent future dependency or wrapper-code regressions.
• Because KEV, ransomware, and exploit-maturity signals are currently low, handle this through normal dependency remediation SLAs unless the application exposes user-controlled ID-generation parameters in sensitive workflows.