CVE-2026-67214

What it actually does

The flaw is an availability issue in the nanoid JavaScript package's non-secure API, specifically nanoid/non-secure. In versions before 5.1.16, the customAlphabet and nanoid functions can enter an infinite loop when called with a negative size value. If an application passes attacker-controlled input into the size argument without validating that it is a positive integer, the affected Node.js thread can spin indefinitely, consuming CPU and preventing normal request handling. The impact is denial of service; the vulnerability does not directly allow code execution, data theft, or data modification.

Why it matters to the business

Applications that expose Nano ID generation size to users or external requests may become unresponsive if an attacker submits a negative size value. This can cause service degradation, failed transactions, increased latency, worker exhaustion, autoscaling cost spikes, and customer-facing outages. The issue is not listed in CISA KEV and there is no reported ransomware use, but it is simple to trigger where the vulnerable call pattern exists, so internet-facing services should treat exposed usage as a practical availability risk.

How an attack unfolds

An attacker first identifies an application feature that generates Nano IDs using the non-secure nanoid API and allows the requested ID length or size to be influenced by request data, such as a query parameter, JSON field, form value, or API option. The attacker then supplies a negative value for that size. If the application passes that value directly to nanoid/non-secure's nanoid or customAlphabet function, vulnerable versions before 5.1.16 decrement the loop counter from a negative starting point and never satisfy the loop termination condition. In a Node.js application this can pin the event loop or worker handling the request, causing requests to hang and reducing available capacity. Repeating the request across workers, containers, or instances can amplify the denial-of-service effect until the service becomes unavailable or operational limits are reached.

How to fix it

Upgrade nanoid to version 5.1.16 or later wherever it is present in direct or transitive dependencies. Because this issue is specifically in nanoid/non-secure, also review code for imports from nanoid/non-secure and replace non-secure ID generation with the secure nanoid API where unpredictability matters. Add server-side input validation so ID sizes are constrained to a safe positive integer range regardless of package version. Reject negative, zero where inappropriate, non-integer, extremely large, NaN, Infinity, or string-coerced numeric values before calling Nano ID functions. If immediate upgrade is not possible, add a wrapper around nanoid and customAlphabet that enforces minimum and maximum size limits, and consider request-rate limiting on endpoints that generate IDs.

How to confirm the fix worked

Confirm that dependency manifests and lockfiles resolve nanoid to 5.1.16 or later, including transitive copies. Use package-manager inspection commands such as npm ls nanoid, pnpm why nanoid, yarn why nanoid, or equivalent software composition analysis tooling. Search application code for imports of nanoid/non-secure and calls to nanoid or customAlphabet where the size argument comes from request-controlled data. Add or run regression tests that pass negative size values and confirm the application rejects them quickly with a controlled error instead of hanging. In staging, exercise relevant API paths with negative, non-integer, and oversized values while monitoring CPU, event-loop delay, request latency, and worker health.

Typical attack path

1. Find an endpoint or workflow that generates identifiers using Nano ID.
2. Determine whether the client can influence the generated ID length or size.
3. Submit a negative size value through a query parameter, request body, form field, or API option.
4. Trigger the vulnerable nanoid/non-secure nanoid or customAlphabet function on a version before 5.1.16.
5. Cause the calling thread or worker to spin indefinitely and stop servicing normal work.
6. Repeat the request to exhaust available workers, CPU, or application capacity.

How to detect it

Look for evidence of denial-of-service attempts against endpoints that generate IDs or accept length, size, idLength, nanoidSize, or similar parameters. Useful log sources include web access logs, API gateway logs, WAF logs, application request logs, APM traces, container or process metrics, Node.js event-loop delay metrics, and error/timeout logs. Investigate bursts of requests with negative numeric values in parameters or JSON fields that control ID size, especially when correlated with high CPU usage, event-loop lag, worker restarts, request timeouts, 499/502/503/504 responses, or hung Node.js processes. In code and build artifacts, search for nanoid/non-secure imports and dynamic calls to nanoid or customAlphabet. Because the vulnerable behavior may hang without throwing an exception, absence of stack traces does not rule out exploitation; correlation between suspicious input and resource exhaustion is the strongest signal.

• nanoid/non-secure
• customAlphabet(
• nanoid(
• size=-
• length=-
• idLength=-
• nanoidSize=-
• "size":-
• "length":-
• "idLength":-
• "nanoidSize":-

What your security team should do

• Prioritize internet-facing applications or APIs where clients can influence generated ID length, size, or format.
• Upgrade all direct and transitive nanoid dependencies to 5.1.16 or later and rebuild/redeploy affected services.
• Search source code and dependency inventories for nanoid/non-secure usage, especially customAlphabet and nanoid calls with dynamic size arguments.
• Implement centralized validation for ID-size parameters: allow only bounded positive integers and reject unsafe values before business logic executes.
• Add regression tests for negative and malformed size inputs on all endpoints that generate identifiers.
• Monitor application telemetry for sudden CPU saturation, event-loop lag, request timeouts, and repeated requests containing negative size parameters.
• If exploitation is suspected, restart stuck workers after capturing relevant logs and runtime telemetry, then deploy validation and dependency fixes before restoring normal traffic.