GHSA-6chw-6frg-f759

What it actually does

Affected versions of the npm package acorn contain a regular expression denial-of-service weakness. When Acorn parses specially crafted JavaScript input, vulnerable regular expression processing can consume excessive CPU time and block the Node.js event loop. The flaw does not provide code execution or data disclosure by itself, but any service that parses attacker-controlled JavaScript, expressions, templates, configuration, source uploads, or build artifacts with a vulnerable Acorn version can be made slow or unavailable.

Why it matters to the business

Applications, developer platforms, CI/CD systems, code analysis services, sandboxes, documentation tooling, or any service that accepts and parses untrusted JavaScript may become unavailable under crafted input. Because Acorn is a widely used JavaScript parser and is often included transitively through build and linting tools, exposure may exist even where the package is not a direct dependency. The issue is old and fixed versions have been available for years, so remaining exposure usually indicates dependency drift or insufficient transitive dependency governance.

How an attack unfolds

An attacker first identifies an application path that causes server-side JavaScript parsing with Acorn, such as source-code upload, online editing, linting, bundling, transpilation, static analysis, import validation, or processing of user-supplied scripts. The attacker then submits crafted JavaScript content designed to trigger pathological regular expression behavior in vulnerable Acorn versions. When the vulnerable parser processes the input, CPU usage spikes and the Node.js event loop can be blocked for an extended period. Repeated requests, concurrent submissions, or automated retries can exhaust application workers and cause request timeouts, queue buildup, failed builds, degraded API performance, or full service unavailability. Exploitation does not require authentication if the parsing function is reachable anonymously; if parsing is restricted to authenticated users, a low-privileged account may still be sufficient.

How to fix it

Upgrade Acorn to a fixed version. For the npm package acorn, use one of the fixed release lines: 5.7.4 or later in the 5.x line, 6.4.1 or later in the 6.x line, or 7.1.1 or later in the 7.x line. Prefer upgrading to the latest maintained Acorn version compatible with the application. Regenerate lockfiles after updating and ensure transitive dependencies are also resolved to fixed versions. If immediate upgrade is not possible, reduce exposure by preventing untrusted users from reaching parser functionality, applying strict input size limits, enforcing request and job timeouts, rate-limiting parsing endpoints, isolating parsing work in worker processes with CPU/time budgets, and queueing or rejecting unusually large or malformed JavaScript inputs.

How to confirm the fix worked

Confirm dependency resolution rather than only checking manifest constraints. Use package-manager tooling such as `npm ls acorn`, `npm audit`, `yarn why acorn`, or `pnpm why acorn` to identify all installed Acorn versions. Inspect package-lock.json, yarn.lock, pnpm-lock.yaml, and deployed artifacts to ensure no vulnerable Acorn versions remain below 5.7.4 in the 5.x line, below 6.4.1 in the 6.x line, or below 7.1.1 in the 7.x line. Rebuild and redeploy from clean dependencies, then run application tests covering JavaScript parsing workflows. Operationally validate that parsing endpoints enforce maximum input size, timeout, concurrency, and rate-limit controls, and that a deliberately long or malformed test input is rejected or terminated quickly rather than consuming sustained CPU.

Typical attack path

1. Find an endpoint, workflow, or background job that parses user-supplied JavaScript or JavaScript-like input.
2. Confirm that the target application or toolchain uses a vulnerable Acorn version, directly or transitively.
3. Submit a crafted JavaScript payload that triggers excessive regular expression processing during parsing.
4. Observe slow responses, request timeouts, worker saturation, or elevated CPU on Node.js processes.
5. Repeat or parallelize submissions to sustain denial of service and impact availability.

How to detect it

There are no widely reliable, vulnerability-specific compromise indicators for this issue because exploitation consists of submitting crafted parser input that causes resource exhaustion. To assess whether exploitation may already have occurred, review application, API gateway, reverse proxy, WAF, job-queue, and CI/CD logs for repeated requests or jobs involving JavaScript parsing that coincide with spikes in CPU usage, Node.js event-loop lag, worker restarts, queue backlogs, HTTP 408/429/499/500/502/503/504 responses, or parsing timeouts. Correlate suspicious time windows with process telemetry showing long-running Node.js processes, high single-core CPU consumption, increased garbage collection, or watchdog terminations. Search application logs for Acorn parsing errors, repeated malformed JavaScript submissions, unusually large source payloads, and repeated activity from the same IP address, account, token, or automation client. If request bodies or submitted files are retained, examine samples submitted immediately before CPU saturation events and reproduce safely in an isolated environment using the deployed parser version to determine whether they trigger abnormal parsing time.

What your security team should do

• Inventory all direct and transitive uses of the npm package acorn across applications, build systems, developer tools, CI/CD jobs, and container images.
• Prioritize internet-facing or multi-tenant services that parse user-supplied JavaScript, source files, templates, plugins, or configuration.
• Upgrade to fixed Acorn versions: 5.7.4, 6.4.1, 7.1.1, or a later maintained release, and regenerate lockfiles.
• Add compensating controls for parser-facing workflows: input size limits, execution timeouts, worker isolation, queue limits, and rate limiting.
• Review dependency-scanning results for stale transitive packages and enforce automated dependency updates for JavaScript ecosystems.
• Monitor Node.js services that perform parsing for sustained high CPU, event-loop lag, request timeouts, and repeated malformed JavaScript submissions.
• Document parser trust boundaries so future features do not pass untrusted input to CPU-intensive parsing routines without resource controls.