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

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

The Vulnerability at a Glance

Introduction

The docs-site/package-lock.json file locks the entire dependency tree for a documentation website — including transitive dependencies that most developers never think about. One of those quiet dependencies, nanoid, is a wildly popular unique ID generator used across the JavaScript ecosystem. But in versions below 3.3.18 and 5.1.6, a flaw in its random ID generation routine means that under specific edge-case conditions, the generation loop can spin forever — burning 100% of one CPU core and making the server completely unresponsive.

This is a textbook CWE-835: Loop with Unreachable Exit Condition vulnerability. The fix is straightforward — a dependency upgrade — but understanding why it matters and how it could be exploited is essential for any developer who ships JavaScript to production.

The Vulnerability Explained

What is nanoid?

nanoid is one of the most downloaded npm packages in existence, used to generate cryptographically strong, URL-friendly unique identifiers. A typical call looks like:

import { nanoid } from 'nanoid';
const id = nanoid(); // "V1StGXR8_Z5jdHi6B-myT"

Under the hood, nanoid uses a rejection-sampling algorithm to generate IDs. It draws random bytes from the platform's CSPRNG (e.g., crypto.getRandomValues in browsers, or crypto.randomFillSync in Node.js), maps them to a character alphabet, and discards bytes that fall outside the valid range to avoid modulo bias.

The Flaw: An Infinite Rejection Loop

The vulnerability (CVE-2026-67213) lives in this rejection-sampling loop. In affected versions (nanoid 3.3.15 was pinned in docs-site/package-lock.json), a specific combination of alphabet size and ID length parameters could produce a situation where the probability of accepting any given random byte approaches zero — meaning the loop retries indefinitely and never terminates.

Here is a simplified representation of the vulnerable pattern:

// Simplified vulnerable pattern (nanoid internals, pre-fix)
const generate = (alphabet, size) => {
  let id = '';
  while (id.length < size) {
    const byte = randomByte();
    // If mask is miscalculated, byte is almost always rejected
    if (byte < alphabet.length) {
      id += alphabet[byte];
    }
    // No iteration limit — loop runs forever if byte is always rejected
  }
  return id;
};

The critical missing control is a bounded iteration count or a fallback exit condition. When the mask calculation produces a range that is incompatible with the available entropy, every byte is rejected and id.length never increments toward size.

The Vulnerable Dependency in This Repository

In docs-site/package-lock.json, nanoid was pinned at version 3.3.15:

// Before fix — docs-site/package-lock.json
"nanoid": {
  "version": "3.3.15",
  ...
}

This version predates the loop-termination fix introduced in 3.3.18.

Real-World Attack Scenario

Consider a documentation site that uses a React-based frontend (as this one does — note "react": "^18.2.0" in the diff) with a Node.js build or server-side rendering step. If any server-side code path calls nanoid() with attacker-influenced parameters — for example, a custom alphabet or size derived from a URL query parameter or API input — an attacker could craft a request that drives nanoid into the infinite loop:

GET /api/generate-link?size=999999&alphabet=a HTTP/1.1

If the server passes size and alphabet directly to nanoid(alphabet, size), the process hangs. With enough concurrent requests, the Node.js event loop starves, and the entire service goes down. Even without direct parameter control, the vulnerability can be triggered if any upstream dependency passes edge-case values into nanoid internally.

The Fix

What Changed in the Pull Request

The PR upgrades nanoid from 3.3.15 to 3.3.18 by updating two files:

• docs-site/package.json
• docs-site/package-lock.json

The core change in package-lock.json updates the resolved version and integrity hash for the nanoid entry:

// Before
"nanoid": {
  "version": "3.3.15",
  "resolved": "https://registry.npmjs.org/nanoid/-/nanoid-3.3.15.tgz",
  "integrity": "sha512-<old-hash>"
}

// After
"nanoid": {
  "version": "3.3.18",
  "resolved": "https://registry.npmjs.org/nanoid/-/nanoid-3.3.18.tgz",
  "integrity": "sha512-<new-hash>"
}

The PR also upgrades several other dependencies as part of the same lockfile refresh:

• katex: bumped from ^0.18.1 to ^0.18.3
• tmmcore: bumped from ^0.1.0 to ^0.2.0
• Multiple platform-specific optional packages had their libc field constraints removed, broadening compatibility

How the Fix Solves the Problem

nanoid 3.3.18 patches the rejection-sampling loop with a bounded retry count and a corrected mask calculation that ensures the acceptance probability remains non-trivially positive for all valid alphabet/size combinations. The fixed internal logic looks conceptually like:

// Fixed pattern (nanoid >= 3.3.18)
const generate = (alphabet, size) => {
  let id = '';
  // Corrected mask ensures bytes are accepted at a reasonable rate
  const mask = (2 << (Math.log(alphabet.length - 1) / Math.LN2)) - 1;
  const step = Math.ceil((1.6 * mask * size) / alphabet.length);

  while (true) {
    const bytes = randomBytes(step);
    for (let i = 0; i < step; i++) {
      const byte = bytes[i] & mask;
      if (byte < alphabet.length) {
        id += alphabet[byte];
        if (id.length === size) return id; // Guaranteed exit
      }
    }
    // step is calculated to make this loop statistically guaranteed to exit
  }
};

The key improvements are:
1. Correct mask calculation — ensures the rejection rate stays low
2. Batch byte generation — processes bytes in statistically sufficient batches
3. Guaranteed termination — the mathematical relationship between step, mask, and alphabet.length ensures the loop exits in finite iterations

Prevention & Best Practices

1. Keep Lock Files Up to Date

A package-lock.json that pins old transitive dependency versions is a liability. Run npm audit and npm update regularly:

# Check for known vulnerabilities
npm audit

# Update all dependencies to latest compatible versions
npm update

# Force-update a specific package
npm install nanoid@latest

2. Integrate Dependency Scanning in CI

This vulnerability was caught by Trivy, a container and filesystem vulnerability scanner. Add it (or a similar tool) to your CI pipeline:

# Example GitHub Actions step
- name: Run Trivy vulnerability scanner
  uses: aquasecurity/trivy-action@master
  with:
    scan-type: 'fs'
    scan-ref: '.'
    severity: 'HIGH,CRITICAL'
    exit-code: '1'

Other excellent tools for this:
- npm audit — built into npm, catches known CVEs
- Snyk — deeper dependency graph analysis
- GitHub Dependabot — automatic PRs for vulnerable dependencies
- Socket.dev — behavioral analysis of npm packages

3. Never Pass Unvalidated Input to ID Generators

Even with a patched nanoid, never let user-controlled values dictate the alphabet or size parameters:

// DANGEROUS — never do this
app.get('/id', (req, res) => {
  const id = nanoid(req.query.size); // User controls loop iterations
  res.json({ id });
});

// SAFE — use fixed, validated parameters
const ID_SIZE = 21; // Fixed constant
app.get('/id', (req, res) => {
  const id = nanoid(ID_SIZE);
  res.json({ id });
});

4. Monitor for CWE-835 Patterns in Your Own Code

Any loop in your codebase that depends on probabilistic exit conditions deserves scrutiny. Apply a maximum iteration guard:

// Add iteration limits to any probabilistic loop
const MAX_ATTEMPTS = 1000;
let attempts = 0;
while (condition && attempts < MAX_ATTEMPTS) {
  // ... loop body
  attempts++;
}
if (attempts >= MAX_ATTEMPTS) {
  throw new Error('Max retry attempts exceeded');
}

Relevant Standards

• CWE-835: Loop with Unreachable Exit Condition
• OWASP A06:2021: Vulnerable and Outdated Components — OWASP Top 10
• OWASP Dependency Check: https://owasp.org/www-project-dependency-check/

Key Takeaways

• nanoid 3.3.15 in docs-site/package-lock.json was vulnerable — lock files that pin old transitive dependencies silently carry CVEs forward until explicitly updated.
• Infinite loop DoS vulnerabilities in ID generators are subtle — the flaw isn't in your application code, it's in a math edge case deep inside a library's rejection-sampling algorithm.
• katex and tmmcore were also bumped in the same PR — dependency refresh PRs often fix multiple issues simultaneously; don't ignore collateral upgrades.
• Removing libc constraints from optional packages (seen throughout the diff) broadens platform compatibility and reduces the chance of falling back to vulnerable native binaries on non-glibc systems.
• Static analysis tools like Trivy can catch CVEs in package-lock.json before they reach production — integrate them early in the development lifecycle, not as an afterthought.

How Orbis AppSec Detected This

• Source: The nanoid package version 3.3.15 declared in docs-site/package-lock.json — a dependency that flows into any code path invoking nanoid() for ID generation.
• Sink: The internal rejection-sampling loop inside nanoid/index.js (nanoid v3 branch) — specifically the while loop that generates random bytes and filters them against an alphabet mask, which can spin indefinitely when the mask is miscalculated.
• Missing control: No maximum iteration bound or statistically guaranteed batch size to ensure the loop terminates within finite steps for all valid alphabet/size combinations.
• CWE: CWE-835 — Loop with Unreachable Exit Condition (Infinite Loop)
• Fix: Upgraded nanoid from 3.3.15 to 3.3.18 in docs-site/package-lock.json, which contains the corrected mask calculation and batch-generation logic that guarantees loop termination.

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 Denial of Service vulnerabilities don't always come from dramatic memory corruption or network floods. Sometimes they come from a math edge case in a 21-character ID generator that's been silently sitting in your lock file for months. The docs-site/package-lock.json file was pinning nanoid@3.3.15 — a version where a specific combination of alphabet size and ID length could cause the random ID generation loop to spin forever, hanging the Node.js process and taking down the service.

The fix is a one-line version bump, but the lesson is broader: your lock file is part of your attack surface. Every pinned version is a commitment to run that exact code in production. Automated scanning tools like Trivy exist precisely to catch these silent regressions before attackers do. Integrate them, act on their findings, and keep your dependency tree current.

References

• CWE-835: Loop with Unreachable Exit Condition
• OWASP A06:2021 – Vulnerable and Outdated Components
• OWASP Dependency Check Project
• nanoid npm package
• Semgrep rules for dependency vulnerabilities
• fix: upgrade nanoid to 3.3.18, 5.1.6 (CVE-2026-67213)