EUVD-2026-31775
GHSA-rrh7-4pj2-xxq8
Severity by source
AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
Primary rating from NVD · only source for this CVE.
CVSS VectorNVD
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
Lifecycle Timeline
5Description PRE-NVD
AnalysisAI
Memory exhaustion in the Perl Archive::Tar module before version 3.10 lets remote attackers cause a denial of service by supplying a crafted tar archive whose per-entry header declares an arbitrarily large size, which the module trusts and uses to drive allocation before reading. The flaw is unauthenticated and network-reachable (CVSS 7.5, A:H only - no confidentiality or integrity impact) but affects only applications that parse untrusted tarballs with this module. There is no public exploit identified at time of analysis and EPSS is very low (0.02%, 4th percentile); the vendor shipped a fix in 3.10.
Technical ContextAI
Archive::Tar is a widely deployed pure-Perl library (CPAN distribution maintained by BINGOS) for reading, writing, and extracting tar archives, identified by CPE cpe:2.3:a:archive::tar_project:archive::tar on the Perl platform. The root cause is CWE-789 (Memory Allocation with Excessive Size Value): the per-entry size field in a tar header is fully attacker-controlled, and versions before 3.10 trusted that declared value during _read_tar without any upper bound. The fix in commit f9af014 introduces a new $Archive::Tar::MAX_FILE_SIZE variable defaulting to 1 GiB and, in _read_tar, refuses entries whose declared size exceeds it ('refusing to allocate', next LOOP) before any read allocation occurs - confirming that the pre-3.10 behavior allocated according to the unvalidated header size.
RemediationAI
Vendor-released patch: 3.10 - upgrade Archive::Tar to 3.10 or later (or apply your distribution's backported package; Debian tracks the relevant releases). The 3.10 release enforces a default 1 GiB cap via $Archive::Tar::MAX_FILE_SIZE, which can be lowered to tighten the bound for memory-constrained services or set to 0 to disable the cap (not recommended). Where immediate upgrade is not possible, apply application-level compensating controls: avoid feeding untrusted tar archives to Archive::Tar, validate or reject oversized declared sizes before extraction, and constrain the worker process memory (e.g., per-process RLIMIT_AS / ulimit -v or container memory limits) so a single malicious archive crashes only the worker rather than the host - the trade-off being that legitimate large archives may also be rejected under tight limits. Refer to the advisory at https://www.openwall.com/lists/oss-security/2026/05/26 and the changelog at https://metacpan.org/release/BINGOS/Archive-Tar-3.10/changes.
Same technique Information Disclosure
View allVendor StatusVendor
Debian
| Release | Status | Fixed Version | Urgency |
|---|---|---|---|
| bullseye | vulnerable | 5.32.1-4+deb11u3 | - |
| bullseye (security) | vulnerable | 5.32.1-4+deb11u5 | - |
| bookworm | vulnerable | 5.36.0-7+deb12u3 | - |
| bookworm (security) | vulnerable | 5.36.0-7+deb12u2 | - |
| trixie | vulnerable | 5.40.1-6 | - |
| forky, sid | vulnerable | 5.40.1-7 | - |
| (unstable) | fixed | (unfixed) | - |
Share
External POC / Exploit Code
Leaving vuln.today