EUVD-2026-97878
GHSA-m6wr-6wgx-82mm
Attack ChainAIDerived
Hypothetical attack flow derived from CVE metadata – not a confirmed exploit chain
-
AccessCraft tar with non-octal size byte
-
DeliveryDeliver archive to unpackTar() endpoint
-
ExploitreadOctal() yields negative entry size
-
ExecutionUnpacker buffers chunks without bound
-
ImpactProcess memory exhausted, service crashes (DoS)
Vulnerability Assessment
| Weakness |
CWE
ASVS 5.0
V2 - Validation and Business Logic Input size validation
|
| Exploitation Conditions | Exploitation requires that the application pass attacker-influenced archive data into modern-tar's unpackTar() (or the streaming/filesystem decoders) in the default non-strict mode; the malicious input is a tar header whose size field at the USTAR size offset contains any non-octal byte (e.g. '/', '8', '9', ':'), parsed by readOctal(). The archive may be plain or gzip-compressed. The primary LIMITING factor is exposure rather than configuration: the attacker must reach a code path that unpacks untrusted archives with this library version (0.3.5-0.8.5). Using the library's strict mode mitigates by throwing on the malformed header instead of buffering, so deployments that enable strict parsing or only process trusted archives are not realistically exploitable. |
| Impact | The CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:N/UI:N) describes a remotely reachable, low-complexity, unauthenticated flaw, but the impact is strictly availability (VC:N/VI:N/VA:H) - this is a denial-of-service via memory exhaustion, not a code-execution or data-disclosure bug, despite the input's 'Information Disclosure' tag which contradicts the vector and should be disregarded. The 8.7 'High' score reflects easy triggering rather than catastrophic impact: an attacker only needs to get a crafted archive parsed by unpackTar(). No EPSS score, no CISA KEV listing, and no standalone exploit were provided, so this is not confirmed as actively exploited; however, the public fix commit (181c8cb) and detailed regression tests make the trigger condition trivially reproducible, raising practical exploitability for anyone reading the advisory. Real priority is governed by exposure: the actual risk depends entirely on whether an application feeds attacker-controlled (including gzip-compressed) tar input into this specific library - where it does, this is a genuine low-effort DoS; where tar input is trusted, residual risk is minimal. |
| Exploit ScenarioDerived | An application uses modern-tar (0.3.5-0.8.5) to unpack user-uploaded or network-fetched archives. An attacker uploads a crafted, optionally gzip-compressed, tar archive whose entry header contains a non-octal byte in the size field, causing readOctal() to compute a negative entry size; unpackTar() then buffers incoming chunks indefinitely until the Node.js process exhausts memory and crashes. No public exploit is identified, but the fix commit and tests make the malformed-header trigger straightforward to reproduce. |
Get an e-mail when this CVE is exploited, patched or re-scored. Free account.
Alert meAnalysisAIv1 – Oct 12, 2026
Memory exhaustion in modern-tar versions 0.3.5 through 0.8.5 lets remote, unauthenticated attackers crash or stall any process that unpacks an attacker-supplied tar archive, because a size field containing a non-octal byte (such as '/', '8', '9' or ':') is parsed by readOctal() into a negative entry size that the unpacker then buffers against indefinitely - the malicious archive may also be gzip-compressed. The impact is availability only (CVSS 4.0 8.7, assessed CVSS 3.1 8.1 with VC:N/VI:N/VA:H): no code execution or data disclosure is demonstrated, and the upstream 'Information Disclosure' tag is not supported by either vector. No public exploit code and no CISA KEV entry were identified at time of analysis; the practical limiting factor is exposure and configuration, since deployments that enable the library's strict parsing mode, or that only unpack trusted archives, throw on the malformed header instead of buffering and are not realistically exploitable.
RemediationAI
Apply the upstream fix by moving off modern-tar 0.3.5-0.8.5 to a release that includes commit 181c8cb (PR #195), which adds octal-digit validation to readOctal(); because the supplied intelligence points to a GitHub commit/PR rather than a tagged release, treat this as upstream fix available (PR/commit) with the released patched version not independently confirmed, and verify the changelog before pinning. If an upgrade cannot be scheduled immediately, instantiate every decoder in strict mode ({ strict: true } for createUnpacker/createTarDecoder/unpackTarFS) so that a malformed size field throws 'Invalid tar number.' and no body buffering occurs - the trade-off, visible in the upstream tests, is that strict mode also rejects archives the library previously tolerated (for example corrupt checksums or trailing garbage), so loosen only if your own producer guarantees clean headers. Additional compensating controls with their costs: wrap the input stream in a hard byte/size cap (e.g. a counting transform that aborts above an expected archive size) to bound worst-case memory, at the risk of rejecting legitimately large archives; run untrusted unpacking in a worker/subprocess with an enforced heap limit (--max-old-space-size or container memory limits) so exhaustion kills only the sandboxed worker rather than the host service; and prefer streaming extraction to disk over fully buffered unpackTar() so peak memory is bounded by chunk size. Never rely on decompressing gzip first as a mitigation - the malformed header survives decompression unchanged. Reference advisories: https://www.vulncheck.com/advisories/modern-tar-0.3.5-through-0.8.5-memory-exhaustion-via-malformed-octal-size-field, https://github.com/ayuhito/modern-tar/commit/181c8cb75351867535057817ada4802a90fe416e, and https://github.com/ayuhito/modern-tar/pull/195.
Affected VersionsENISA
Affected Packages
Source: OSV (Open Source Vulnerabilities)
Affects your stack
Affects 1 package in euvd
Checking this CVE against your own stacks and servers is part of the Basic plan and up.
Technical ContextAI · show details
modern-tar is a JavaScript/TypeScript tar archiving library for Node.js and web runtimes (npm package, GitHub ayuhito/modern-tar) that implements its own USTAR header codec rather than shelling out to the system tar. The root cause is CWE-1284 (Improper Validation of Specified Quantity in Input): readOctal() in src/tar/encoding.ts decodes the fixed-width octal size field at USTAR_SIZE_OFFSET without verifying that each byte falls in the octal digit range 0x30-0x37 ('0'-'7'). Any other byte produces a nonsensical, effectively negative entry size; instead of rejecting the header, the default non-strict decoder accepts it, enters body state, and keeps requesting/buffering chunks for a length that never legitimately terminates, consuming process memory while also suppressing the parsing of any later, valid entries in the same stream. The flaw applies to the buffered unpackTar() path, the streaming createTarDecoder(), and the filesystem extractor unpackTarFS() alike, and gzip wrapping is irrelevant to the bug because decompression simply delivers the same malformed header. The upstream correction (commit 181c8cb, PR #195) adds a single range check inside readOctal() - 'if (charCode < 48 || charCode > 55) throw new Error("Invalid tar number.")' - and a new tests/tar/numeric.test.ts asserts that strict decoders throw while non-strict decoders skip the bad header and continue with the next valid entry.
Know when the next one hits your stack
- Watch products and get an email when something new is published
- Check this CVE against your own stack and servers
- Exploit and PoC references, threat intelligence from 22 sources
No credit card · 7-day full trial
Severity by source
CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N
Remotely parseable crafted archive needs no auth or interaction (AV:N/AC:L/PR:N/UI:N); impact is memory-exhaustion DoS only, so C:N/I:N/A:H.
Primary rating from Vendor (vulncheck).
CVSS VectorVendor: vulncheck
DescriptionCVE.org
modern-tar 0.3.5 through 0.8.5 contains a memory exhaustion vulnerability that allows attackers to produce negative entry sizes via non-octal bytes parsed by readOctal(). Attackers can supply a crafted, optionally gzip-compressed, archive to unpackTar() that buffers chunks indefinitely, exhausting process memory and suppressing later entries.
Executive ViewAI
Organizations using the modern-tar library versions 0.3.5 through 0.8.5 to unpack untrusted tar archives face a high-severity availability risk: a remote attacker can crash or indefinitely stall affected processes through memory exhaustion. This vulnerability only impacts availability; there is no risk of code execution or data disclosure. Leadership should care because critical services that process user-supplied tar files could be disrupted, though configurations that enforce strict parsing or only handle trusted archives are not realistically exploitable.
Enable the library's strict parsing mode; restrict unpacking to trusted tar archives only; consider input validation to reject malformed tar headers.
Threat Intelligence Overview
NVD
CVE.org
EPSS
Vulnrichment
How this decision was reached
The engine reads each signal below and applies a fixed list of rules from top to bottom. The first rule that matches sets the recommended action – like a statement, every line is shown.
What every action level means
SSVC AssessmentENISA
Priority Score
Attack Technique
Denial of Service attacks render applications or systems unavailable by overwhelming resources or triggering failure conditions.
Exploit-DB