How Denial of Service via Infinite Loop happens in JavaScript dependency nanoid and how to fix it

How Denial of Service via Infinite Loop Happens in JavaScript Dependency nanoid and How to Fix It

Vulnerability at a Glance

Introduction

The bun.lock file in this repository pinned nanoid at version 3.3.12. That version contains a flaw deep inside the customAlphabet random ID generation path: under specific input conditions, the internal rejection-sampling loop never finds a valid byte, spinning the CPU to 100% and blocking the Node.js event loop until the process is killed or the server crashes. Because nanoid is a transitive dependency pulled in by many popular build tools and Vue.js toolchains, this vulnerability is far more widespread than its package name might suggest.

The Trivy scanner detected the pinned "nanoid@3.3.12" entry in bun.lock and matched it against the CVE-2026-67213 advisory. The fix is a two-file change: bump the version in package.json and regenerate bun.lock to record the patched 3.3.18 hash.

The Vulnerability Explained

What nanoid's customAlphabet does

nanoid generates cryptographically random string identifiers. Its customAlphabet(alphabet, size) function lets callers define their own character set. Internally, it uses a rejection-sampling algorithm:

1. Generate a pool of random bytes.
2. For each byte, apply a bitmask so the value falls within the alphabet length.
3. If the masked value is a valid index, accept it; otherwise, reject and retry.

The bitmask is computed as the smallest power-of-two mask that covers the alphabet size. For most alphabet sizes this works fine. However, in vulnerable versions before 3.3.18, a specific combination of alphabet size and pool sizing causes the rejection rate to approach 100%, meaning the inner loop never accumulates enough accepted bytes to fill the requested ID length — it simply loops forever.

The vulnerable entry in bun.lock

# BEFORE (vulnerable)
"nanoid": ["nanoid@3.3.12", "", { "bin": "bin/nanoid.cjs" },
  "sha512-ZB9RH/39qpq5Vu6Y+NmUaFhQR6pp+M2Xt76XBnEwDaGcVAqhlvxrl3B2bKS5D3NH3QR76v3aSrKaF/Kiy7lEtQ=="],

This single line is the evidence Trivy matched: the version string 3.3.12 falls within the vulnerable range < 3.3.18.

How an attacker could exploit this

In this web application context, the attack surface depends on how nanoid is invoked. Consider a common pattern where a server-side route generates a session token or short link using a caller-supplied alphabet:

// Hypothetical vulnerable usage
import { customAlphabet } from 'nanoid'; // 3.3.12

app.post('/shorten', (req, res) => {
  const alphabet = req.body.alphabet ?? 'ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz';
  const nanoid = customAlphabet(alphabet, 10);
  res.json({ id: nanoid() }); // ← hangs forever with crafted alphabet
});

An attacker sends a single POST request with a carefully crafted alphabet value that triggers the infinite loop condition. Because Node.js is single-threaded, the event loop is now completely blocked — no other request can be processed. The server is effectively down until restarted. No authentication is required; one HTTP request is sufficient.

Even without direct customAlphabet exposure, the vulnerability can be triggered indirectly through any library that wraps nanoid with a custom alphabet internally.

Real-world impact for this application

This is a Vue 3 web application (evident from the vue@^3.5.13 dependency in bun.lock). The nanoid package is used at minimum as part of the Vite/Vue toolchain. If any server-side route — or a server-side rendering layer — calls nanoid's custom alphabet path with user-influenced parameters, a single malformed request causes a complete DoS. Given the HIGH severity rating, the blast radius justifies an immediate upgrade even before reachability is fully confirmed.

The Fix

What changed in bun.lock

The diff shows a precise, surgical change:

# bun.lock — BEFORE
-    "nanoid": ["nanoid@3.3.12", "", { "bin": "bin/nanoid.cjs" },
-      "sha512-ZB9RH/39qpq5Vu6Y+NmUaFhQR6pp+M2Xt76XBnEwDaGcVAqhlvxrl3B2bKS5D3NH3QR76v3aSrKaF/Kiy7lEtQ=="],

# bun.lock — AFTER
+    "nanoid": ["nanoid@3.3.18", "", { "bin": { "nanoid": "bin/nanoid.cjs" } },
+      "sha512-DTg4MJbGMWkfi6VZFdNt2/caMbQy4Ou+Op/hJQvGEWcnVfoA1QA+xzRKAzw9jD6+GVOOeYr/mIcuDSdug6F6+w=="],

Three things changed in this one line:

The package.json change (not shown in the diff snippet) adds "nanoid": "3.3.18" as an explicit direct dependency, which overrides any transitive resolution to the older version:

# package.json — AFTER
+        "nanoid": "3.3.18",

Pinning it explicitly as a direct dependency is the correct approach here: it ensures that even if a transitive dependency still requests ^3.3.0, Bun's resolver honours the explicit override and installs 3.3.18.

Why 3.3.18 fixes the infinite loop

The nanoid maintainers corrected the pool-size calculation in the rejection-sampling loop. The fix ensures the pool is always sized large enough that the probability of filling the requested ID length in a single pass is bounded away from zero — mathematically guaranteeing termination regardless of alphabet size. This is a pure internal logic fix; the public API (nanoid(), customAlphabet(), urlAlphabet) is unchanged.

Key Takeaways

• nanoid@3.3.12 in bun.lock is directly exploitable — the version string alone is sufficient for Trivy to flag it; no source-code analysis is needed.
• One crafted HTTP request can block the entire Node.js event loop — because the infinite loop runs synchronously, it starves all other requests, making this a single-packet DoS.
• Pinning nanoid as a direct dependency in package.json is the right override strategy — it prevents transitive resolution from silently downgrading back to a vulnerable version.
• The bin field change (string → object) in bun.lock is a harmless metadata normalisation, not a breaking change — safe to accept as part of the upgrade.
• Even "build-tool-only" dependencies carry runtime risk in SSR or full-stack Vue applications where the same node_modules tree serves both build and runtime.

How Orbis AppSec Detected This

• Source: The bun.lock file records nanoid@3.3.12 as a resolved dependency, making the vulnerable version observable to any scanner that reads the lock file.
• Sink: Any call to customAlphabet() inside nanoid/index.js (v3.3.12) where the rejection-sampling loop iterates without a guaranteed exit — effectively while (id.length < size) { ... } with a miscalculated pool.
• Missing control: No upper bound or pool-size correction on the rejection-sampling loop; the loop exit condition is mathematically unreachable for certain alphabet sizes.
• CWE: CWE-835 — Loop with Unreachable Exit Condition (Infinite Loop).
• Fix: Upgraded nanoid from 3.3.12 to 3.3.18 in both bun.lock and package.json, replacing the vulnerable loop logic with a corrected pool-size calculation.

Orbis AppSec automatically detected this vulnerability and opened a pull request with the fix. Try Orbis AppSec on your repositories to find and fix issues like this automatically.

Conclusion

CVE-2026-67213 is a reminder that even small, widely trusted utility libraries can harbour high-severity vulnerabilities. nanoid is downloaded hundreds of millions of times per month precisely because it is simple and reliable — but version 3.3.12 contains a loop that an attacker can weaponise to take down a Node.js server with a single request. The fix is as simple as a version bump, but the window between disclosure and patching is where real damage happens.

Keep your lock files under continuous scanner scrutiny, treat dependency upgrades as security patches (not just maintenance), and never expose internal ID-generation parameters to user-controlled input. The two-line change shown here — updating the version in package.json and regenerating bun.lock — is all it takes to close this vulnerability entirely.