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 src-frontend/package-lock.json file in this project locked nanoid at version 3.3.17 — one patch release behind a critical security fix. That single version number meant that any code path invoking nanoid's customAlphabet function with certain edge-case inputs could spin the Node.js event loop into an infinite loop, freezing the entire frontend build server or SSR process until it was forcibly killed. No crash dump, no error message — just silence and 100% CPU.

This post walks through exactly what went wrong inside nanoid, how an attacker could exploit it, and what the upgrade to 3.3.18 / 5.1.6 actually changes.

The Vulnerability Explained

What nanoid Does

nanoid is one of the most widely used JavaScript libraries for generating short, URL-safe unique IDs. It appears in virtually every modern JavaScript frontend and backend project — often pulled in transitively by routers, form libraries, or component frameworks. Its API includes a customAlphabet function that lets callers define their own character set:

import { customAlphabet } from 'nanoid';
const nanoid = customAlphabet('ABCDEF123456', 10);
nanoid(); // e.g. "A3B1C2D4E5"

The Root Cause: A Loop That Can Never Exit (CWE-835)

nanoid's random ID generation uses a rejection-sampling algorithm. To avoid modulo bias (where some characters appear more frequently than others), it generates random bytes and discards any that fall outside the usable range for the given alphabet size. In pseudocode, the inner loop looks like this:

// Simplified illustration of the vulnerable pattern (pre-3.3.18)
let id = '';
while (id.length < size) {
  const byte = randomByte();
  const index = byte & mask;   // mask derived from alphabet length
  if (index < alphabet.length) {
    id += alphabet[index];
  }
  // If byte > alphabet.length, loop continues — forever if mask is wrong
}

The vulnerability (CVE-2026-67213) arises when the computed mask value is inconsistent with the alphabet length in a way that makes it mathematically impossible for any generated byte to satisfy index < alphabet.length. When that condition is never true, the while loop never appends a character, id.length never reaches size, and the loop runs forever.

How an Attacker Triggers It

Because nanoid is frequently used to generate IDs for user-facing objects (form keys, session tokens, component IDs), an attacker who can influence:

1. The alphabet string passed to customAlphabet, or
2. The requested ID length passed to the returned generator function

…can craft a payload that triggers the infinite loop. In a server-side rendering context or a Node.js API that generates IDs on demand (e.g., POST /api/sessions), a single malicious request would hang the worker process permanently, requiring a restart and causing a full Denial of Service for all concurrent users.

Even in a purely frontend context, a build-time or SSR invocation with a crafted alphabet can hang the build pipeline, blocking CI/CD deployments.

Real-World Impact for This Application

The affected file is src-frontend/package-lock.json, which governs the dependency tree for the frontend build. If the frontend performs any server-side rendering, generates IDs at request time, or exposes a Node.js dev server to a network, the vulnerable nanoid version is directly reachable. Even if only used client-side, the locked version creates supply-chain risk and will fail security audits.

The Fix

What Changed in the Upgrade

The PR upgrades nanoid in src-frontend/package-lock.json from 3.3.17 → 3.3.18:

-      "version": "3.3.17",
-      "resolved": "https://registry.npmjs.org/nanoid/-/nanoid-3.3.17.tgz",
-      "integrity": "sha512-xQLf0A3HOMlgHq0n247/LRuAOYmB7dXJ/DvAxGvsSBij45XtBSmQycu+F8ODbHwns/XyFZagyL1+J0Offw1E0g==",
+      "version": "3.3.18",
+      "resolved": "https://registry.npmjs.org/nanoid/-/nanoid-3.3.18.tgz",

The package.json was updated in tandem to ensure the version constraint resolves to the patched release rather than being re-locked to 3.3.17 on the next npm install.

What nanoid 3.3.18 / 5.1.6 Actually Fixes

The patch in nanoid's own source corrects the mask calculation in the rejection-sampling loop so that it is always consistent with the alphabet length. Specifically, the fix ensures that the bitmask applied to random bytes always produces an index value that has a non-zero probability of falling within the valid alphabet range. This guarantees the loop will always terminate in a bounded number of iterations, regardless of the alphabet or size arguments provided.

The fix also adds a maximum iteration guard as a secondary safety net — if for any reason the loop runs an unexpectedly high number of times, it throws a descriptive error rather than hanging indefinitely.

Additional Lock File Cleanup

The diff also removes several libc metadata fields from optional native binary entries (for packages like esbuild and the Mozilla toolkit):

-      "libc": [
-        "glibc"
-      ],

These removals are housekeeping: newer versions of npm no longer require the libc field in package-lock.json for optional platform-specific packages, and their presence in older lock files could cause resolution inconsistencies on musl-based systems (Alpine Linux, etc.). This is unrelated to the CVE but improves the reliability of the lock file across deployment environments.

Prevention & Best Practices

1. Pin Dependencies and Audit Regularly

The core problem here was that 3.3.17 was pinned in package-lock.json without a subsequent security audit. Use automated tools to catch this:

# Audit your current dependency tree
npm audit

# Use Trivy for a comprehensive CVE scan
trivy fs --security-checks vuln src-frontend/package-lock.json

2. Never Pass User-Controlled Data to customAlphabet

Even with the patched version, treat customAlphabet arguments as trusted configuration, not user input:

// ❌ Dangerous: alphabet or size from user input
const nanoid = customAlphabet(req.body.charset, req.body.length);

// ✅ Safe: alphabet and size are hardcoded constants
const nanoid = customAlphabet('ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789', 21);

3. Use Dependabot or Renovate for Automatic Patch PRs

Configure GitHub Dependabot or Renovate Bot to automatically open PRs for patch-level security updates. Both tools integrate with the GitHub Advisory Database and will surface CVEs like this one within hours of disclosure.

# .github/dependabot.yml
version: 2
updates:
  - package-ecosystem: "npm"
    directory: "/src-frontend"
    schedule:
      interval: "weekly"
    open-pull-requests-limit: 10

4. Add Loop Iteration Guards in Custom ID Logic

If you ever write your own rejection-sampling or random generation loops, always include a maximum iteration count:

const MAX_ITERATIONS = 1000;
let iterations = 0;
while (id.length < size) {
  if (++iterations > MAX_ITERATIONS) {
    throw new Error('ID generation exceeded maximum iterations — check alphabet configuration');
  }
  // ... sampling logic
}

5. Relevant Standards

• CWE-835: Loop with Unreachable Exit Condition
• OWASP: Denial of Service Cheat Sheet
• OWASP A06:2021: Vulnerable and Outdated Components — keeping package-lock.json current is a direct mitigation for this category

Key Takeaways

• customAlphabet with edge-case inputs is the trigger: The infinite loop in CVE-2026-67213 is specifically reachable through nanoid's custom alphabet API, not the default nanoid() call. Applications using customAlphabet with any externally influenced arguments are at highest risk.
• A single patch version (3.3.17 → 3.3.18) was the entire fix: The vulnerable window was narrow but real — lock files that don't auto-update can sit on vulnerable patch releases indefinitely without automated scanning.
• package-lock.json is a security artifact: The lock file is not just a reproducibility tool — it encodes the exact versions of every transitive dependency and must be treated as a security-sensitive file, scanned on every CI run.
• The libc field removals in the diff are a bonus hardening step: Removing stale libc metadata from optional native binaries prevents incorrect package resolution on Alpine/musl containers, reducing the chance of accidentally loading a wrong binary artifact.
• Trivy caught this before production: The vulnerability was flagged by static analysis of the lock file, not discovered through an incident — demonstrating the value of integrating SCA (Software Composition Analysis) into CI pipelines.

How Orbis AppSec Detected This

• Source: The nanoid package version 3.3.17 declared in src-frontend/package-lock.json — a user-influenced input surface exists wherever customAlphabet arguments derive from request data or configuration.
• Sink: The rejection-sampling loop inside nanoid's customAlphabet generator function, which in versions before 3.3.18 can enter an unreachable exit condition (CWE-835).
• Missing control: No maximum iteration guard or mask-consistency validation in the pre-patch loop logic; no automated dependency scanning to flag the outdated lock file version.
• CWE: CWE-835 — Loop with Unreachable Exit Condition ('Infinite Loop')
• Fix: Upgraded nanoid from 3.3.17 to 3.3.18 in src-frontend/package-lock.json and src-frontend/package.json, replacing the vulnerable loop implementation with a version that guarantees bounded 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 sharp reminder that even a beloved, widely-audited utility library like nanoid can carry a high-severity vulnerability in a single patch release. The infinite loop in customAlphabet is particularly insidious because it produces no error, no stack trace, and no log entry — just a frozen process and confused users. The fix is a one-line version bump in package-lock.json, but finding that line requires either automated scanning or a very attentive developer.

Keep your lock files current, integrate SCA tools like Trivy into every CI pipeline, and treat customAlphabet arguments as trusted configuration rather than user input. A 30-second npm audit today is worth hours of incident response tomorrow.

References

• CWE-835: Loop with Unreachable Exit Condition
• OWASP Denial of Service Cheat Sheet
• OWASP A06:2021 – Vulnerable and Outdated Components
• nanoid official changelog and release notes
• Semgrep rules for outdated npm dependencies
• fix: upgrade nanoid to 3.3.18, 5.1.6 (CVE-2026-67213)