GHSA-7wwv-vh3v-89cq

What it actually does

Vulnerable highlight.js language grammars use regular expressions that can enter catastrophic backtracking when processing attacker-controlled source-like text. A single crafted input can pin a CPU core and stall the highlighting call indefinitely (or until a timeout), affecting both server-side Node.js rendering and client-side browser sessions. The defect is availability-only: it does not disclose data, execute code, or bypass authentication.

Why it matters to the business

Applications that syntax-highlight untrusted content (documentation portals, pastebins, chat, CI logs, markdown preview, CMS plugins) can be taken offline or made unresponsive, producing user-facing outages and support load. The issue has been public since December 2020, is not on CISA KEV, has no recorded in-the-wild exploitation, and is not associated with ransomware; residual risk is mainly unpatched long-tail npm and CDN deployments of highlight.js and @highlightjs/cdn-assets.

How an attack unfolds

An attacker finds a page or API that runs highlight.js on user-supplied or attacker-influenced text using a pre-10.4.1 grammar set. They submit a short, highly repetitive snippet that matches a vulnerable grammar's regular expressions in a way that forces exponential backtracking. When the library highlights that snippet, the regex engine consumes CPU until the process, worker, or browser tab hangs, denying service to other users of that instance. No privileged access or secondary payload is required; success depends only on the application highlighting untrusted input with an affected version.

How to fix it

Upgrade highlight.js (npm) and @highlightjs/cdn-assets (npm) to 10.4.1 or later; both packages list 10.4.1 as the first fixed release. Prefer a currently supported 10.x/11.x line rather than staying on 10.4.1 long-term. Rebuild and redeploy any bundled, vendored, or CDN-copied copies (including static assets and documentation generators). If an immediate upgrade is not possible, do not highlight untrusted input, constrain highlighted languages to a vetted subset, impose strict size and time limits around highlighting, and run highlighting in an isolated worker with a hard CPU/time budget. After upgrade, regenerate lockfiles and refresh CDN cache-busting URLs so clients do not keep serving the old bundle.

How to confirm the fix worked

Inspect package-lock.json, yarn.lock, pnpm-lock.yaml, and bundled dist files for highlight.js or @highlightjs/cdn-assets versions below 10.4.1. Confirm production, staging, and static/CDN assets resolve to 10.4.1 or newer (check script URLs and file headers). Exercise syntax highlighting of representative untrusted samples under a CPU/time budget and verify the call returns promptly. SCA, npm audit, and software-bill-of-materials scans should no longer report GHSA-7wwv-vh3v-89cq after the upgrade is fully rolled out.

Typical attack path

1. Locate an application or site that highlights user-controlled text with highlight.js or @highlightjs/cdn-assets older than 10.4.1
2. Submit or inject a crafted code-like snippet targeting a known-vulnerable grammar
3. Trigger highlighting (page load, preview, API render, or build-time processing)
4. Observe CPU saturation or request hang as the regular expression engine backtracks
5. Repeat or automate submissions to sustain denial of service against the process or user session

How to detect it

This class of issue rarely leaves a distinct exploit artifact. Hunt for availability symptoms coinciding with syntax-highlighting of untrusted content: Node.js or browser processes pegged at 100% CPU inside highlight.js, requests that never return from a highlight/render path, worker timeouts, and sudden spikes in latency on documentation, paste, or markdown-preview endpoints. Review access and application logs around those events for unusually large or highly repetitive posted snippets. Compare deployed bundle versions and CDN URLs against 10.4.1 to distinguish exposure from confirmed abuse. There are no named threat actors or public exploit kits associated with this advisory, so actor-specific hunting is not applicable.

What your security team should do

• Inventory all npm, CDN, and vendored uses of highlight.js and @highlightjs/cdn-assets and upgrade each to 10.4.1 or later
• Treat leftover copies in static sites, documentation generators, and browser bundles as first-class patch targets, not just server lockfiles
• Until patched, stop highlighting untrusted content or isolate highlighting behind timeouts and worker resource limits
• Do not prioritize this as an active KEV/ransomware emergency; schedule it as standard availability hardening given age, lack of known exploitation, and exploit maturity of None
• Add regression coverage so future grammar or dependency updates cannot reintroduce unbounded regex highlighting of untrusted input