CVE-2024-21538

What it actually does

This is a Regular Expression Denial of Service vulnerability in the Node.js cross-spawn package. Vulnerable versions before 6.0.6 and versions 7.0.0 through 7.0.4 perform insufficient input sanitization before applying a regular expression to command-related input. A very large, specially structured string can cause excessive regex backtracking, consuming CPU and blocking the Node.js event loop or the calling process. The impact is availability loss: the affected application can become unresponsive, time out, crash, or be restarted by a supervisor. The flaw does not by itself provide code execution, privilege escalation, or data disclosure.

Why it matters to the business

Applications or services that use vulnerable cross-spawn versions may be knocked offline if attacker-controlled input reaches the vulnerable parsing path. In practical terms, this can cause API outages, failed automation jobs, delayed background processing, degraded CI/CD pipelines, or instability in services that spawn subprocesses based on user-supplied or external data. The CVSS availability impact is high, but current exploitation signals are lower: it is not listed in CISA KEV, is not reported as ransomware-used, has low EPSS, and has no known mature public exploitation in the provided data. Because the issue has been public for a long time, organizations should treat internet-exposed or automation-heavy Node.js services as higher priority even if broad exploitation has not been observed.

How an attack unfolds

An attacker first needs a reachable feature where externally supplied text is ultimately passed to code that invokes cross-spawn, typically as a command, argument, script name, package manager command, job parameter, or automation input. The attacker then submits an unusually large string crafted to trigger inefficient regular-expression behavior in vulnerable cross-spawn parsing logic. When the application processes the request or job, the vulnerable regex consumes excessive CPU. In a Node.js service, this can block the event loop; in worker-style architectures, it can tie up one or more workers. Repeating the request can exhaust process capacity, trigger watchdog restarts, fill queues, and make the dependent service unavailable. Successful exploitation is usually visible as high CPU usage, request timeouts, worker crashes, or repeated process restarts rather than as a persistent file, account, or command-execution artifact.

How to fix it

Upgrade cross-spawn to a fixed version: 6.0.6 or later for the 6.x line, or 7.0.5 or later for the 7.x line. If consuming the upstream Git source, include commit 085268352dcbcad8064c64c5efb25268b4023184 or a later fixed revision. For Ubuntu packaged Ganeti deployments, use the fixed package versions: ganeti 2.15.2-3 for Ubuntu 16.04 LTS and ganeti 2.16.0~rc2-1build1 for Ubuntu 18.04 LTS. Regenerate lockfiles after upgrading and verify that transitive dependencies no longer resolve to cross-spawn versions before 6.0.6 or 7.0.0 through 7.0.4. Where immediate patching is not possible, reduce exposure by validating and length-limiting inputs that can influence spawned commands, rejecting unusually long command or argument strings, applying request and job timeouts, rate-limiting unauthenticated endpoints, isolating worker processes, and using process supervisors with backoff to avoid restart storms.

How to confirm the fix worked

Confirm dependency resolution rather than only checking top-level package manifests. Use package manager tooling such as npm ls cross-spawn, yarn why cross-spawn, pnpm why cross-spawn, or software composition analysis to verify that no deployed artifact contains cross-spawn before 6.0.6 or 7.0.0 through 7.0.4. Inspect package-lock.json, yarn.lock, pnpm-lock.yaml, bundled node_modules directories, container images, serverless bundles, and CI runner images. For Ubuntu Ganeti systems, verify the installed ganeti package version is at or above the fixed version for the distribution. Validate mitigations by confirming maximum input length checks, request timeouts, worker execution time limits, and rate limits are active on any endpoint or workflow that can influence process-spawning behavior. In staging only, test with oversized benign inputs to confirm the application rejects them quickly and does not pin CPU or block the event loop.

Typical attack path

1. Identify an application, API, worker, CI job, or automation service that depends on a vulnerable version of cross-spawn.
2. Find an input field or workflow parameter that is later used in process-spawning logic.
3. Send a very large, specially crafted string that reaches the vulnerable cross-spawn regular expression path.
4. Cause excessive regex backtracking, resulting in high CPU consumption and blocked processing.
5. Repeat or parallelize the requests to sustain denial of service, increase queue backlogs, or force application restarts.

How to detect it

There is no reliable single artifact that proves exploitation because this denial-of-service issue does not normally create files, accounts, malware processes, or command-execution traces. Detection should focus on behavioral evidence correlated with vulnerable deployments. Review application logs, reverse proxy logs, API gateway logs, WAF logs, job queue logs, process supervisor logs, container orchestration events, and host telemetry for sudden CPU saturation, event-loop lag, request timeout spikes, worker crashes, restart loops, or job failures immediately after requests containing unusually long command-like parameters, script names, package names, arguments, or automation inputs. In Node.js services, look for prolonged synchronous processing, blocked event loop warnings, unhandled timeout errors, health-check failures, and process restarts without corresponding memory pressure or external dependency outages. In HTTP logs, investigate repeated large requests from the same source, bursts of 4xx/5xx/499/502/503/504 responses, unusually large query strings or request bodies, and requests to endpoints that launch subprocesses or run automation. For CI/CD or job-runner environments, review submitted job parameters and queue history for oversized values preceding runner CPU exhaustion or termination. Use dependency telemetry to scope investigations to systems that actually contained vulnerable cross-spawn versions during the suspected time window.

What your security team should do

• Inventory all applications, containers, build agents, automation workers, and packaged products that include cross-spawn or Ganeti.
• Prioritize remediation for internet-facing services, unauthenticated APIs, job queues, CI/CD systems, and automation platforms where external or semi-trusted users can influence command or argument strings.
• Upgrade cross-spawn to 6.0.6 or 7.0.5 or later, and update Ubuntu Ganeti packages to the fixed distribution versions where applicable.
• Regenerate and redeploy lockfiles and container images so transitive vulnerable versions are actually removed from runtime artifacts.
• Add input length limits and allow-list validation before any data is passed to process-spawning code.
• Configure request timeouts, worker job timeouts, rate limits, circuit breakers, and supervisor backoff to reduce denial-of-service impact.
• Monitor for high CPU, event-loop lag, repeated worker restarts, request timeout spikes, and queue backlog growth around endpoints or jobs that invoke subprocesses.
• Because this is not currently KEV-listed and has low EPSS, align emergency response with exposure: patch exposed or externally influenced systems first, then complete dependency hygiene across internal services.