CVE-2026-59874

What it actually does

CVE-2026-59874 is a denial-of-service flaw in the Node.js tar archive library before version 7.5.18. The vulnerable tar.replace archive scanning logic can accept a checksum-valid tar header containing a negative base-256 encoded entry size. Because the parsed entry size is negative, the scanner fails to advance through the archive and repeatedly parses the same header, causing the process to hang or consume CPU indefinitely. Any service that accepts or processes attacker-controlled tar archives using vulnerable node-tar code may be susceptible, including upload handlers, package/artifact ingestion services, build systems, and archive transformation workflows.

Why it matters to the business

Successful exploitation can make affected Node.js services unavailable, stall archive-processing jobs, exhaust worker capacity, and disrupt dependent business workflows such as file uploads, CI/CD artifact handling, package processing, or backup/import features. The CVSS availability impact is high and public exploitability is reported, but EPSS is currently low and the issue is not listed in CISA KEV, so remediation should be prioritized for internet-facing or automated archive-processing systems first.

How an attack unfolds

An attacker creates a tar archive with a syntactically valid header checksum but encodes the entry size as a negative base-256 value. The attacker then submits that archive to an application path that invokes vulnerable node-tar tar.replace processing, such as an upload endpoint, artifact ingestion API, package processing pipeline, or backend job that modifies tar contents. When the vulnerable scanner reaches the malicious header, it repeatedly reprocesses the same header without moving forward in the archive. This can pin a Node.js event loop or worker process, cause requests or jobs to hang until external timeout, and degrade or deny service if repeated across multiple workers or instances.

How to fix it

Upgrade node-tar to version 7.5.18 or later everywhere it is used, including transitive dependencies. Use package-manager tooling such as npm ls tar, yarn why tar, pnpm why tar, npm audit, lockfile review, and dependency overrides/resolutions to ensure no vulnerable version below 7.5.18 remains in production builds. Rebuild and redeploy affected Node.js services after updating lockfiles and containers. As defense in depth, reject malformed archives before deep processing, enforce maximum archive size and entry count, run archive manipulation in isolated worker processes, apply strict CPU/request/job timeouts, limit upload rates, and ensure stuck workers can be killed and restarted without affecting the primary service.

How to confirm the fix worked

Confirm the deployed dependency tree resolves node-tar to 7.5.18 or later using npm ls tar, yarn why tar, pnpm why tar, SBOM comparison, or container image scanning. Verify lockfiles and production artifacts do not include vulnerable tar versions below 7.5.18. In staging only, validate that malformed tar archives with invalid or negative size encodings are rejected or fail safely within expected timeouts rather than hanging. Monitor archive-processing endpoints and jobs after deployment to confirm CPU, queue depth, timeout rates, and worker restarts return to normal baselines.

Typical attack path

1. Identify an application, API, or automation workflow that accepts tar archives or tar-like package artifacts.
2. Craft a tar archive containing a checksum-valid header with a negative base-256 encoded size field.
3. Submit the archive through an unauthenticated or low-friction ingestion path, if one is exposed.
4. Trigger backend processing that calls vulnerable node-tar tar.replace logic.
5. Cause the archive scanner to repeatedly parse the same header without progress.
6. Repeat submissions or target concurrent workers to exhaust CPU, worker slots, request capacity, or job queues.

How to detect it

To determine whether exploitation already occurred, review telemetry for systems that accept or process tar archives: web access logs, API gateway logs, upload service logs, background job logs, CI/CD artifact processing logs, container/runtime metrics, process supervision logs, and Node.js diagnostic reports. Look for requests or jobs involving tar uploads that run until timeout, produce 499/502/503/504 responses, consume high CPU with little I/O, or require worker restarts. Correlate these events with repeated submissions from the same IP address, user agent, account, API token, or automation source. Inspect retained suspicious archives offline with safe tooling or custom parsers, focusing on tar header size fields that use base-256 encoding and represent negative values while still having a valid header checksum. Memory or CPU profiles may show Node.js workers stuck in tar parsing or replacement code paths. Because the vulnerability causes a parser hang rather than a distinctive command execution artifact, absence of explicit error messages does not rule out exploitation.

What your security team should do

• Immediately inventory Node.js applications, build systems, artifact processors, and upload workflows that use node-tar or accept tar archives from users, partners, CI systems, or external automation.
• Prioritize patching internet-facing, unauthenticated, multi-tenant, or high-volume archive-processing services to node-tar 7.5.18 or later.
• Use dependency overrides or resolutions where tar is pulled in transitively and a direct upstream dependency has not yet released an update.
• Add operational controls: request body limits, archive entry limits, processing timeouts, worker isolation, rate limiting, and automatic stuck-worker termination.
• Search recent logs and telemetry for archive-processing hangs, request timeouts, CPU spikes, and repeated submissions of tar files from the same sources.
• Retain suspicious archive samples for offline analysis, but do not process them with vulnerable tooling.
• Add regression tests to ensure malformed tar headers cannot cause non-terminating archive scans.