+ "details": "## Summary\n\nVersions of `astral-tokio-tar` prior to 0.5.6 contain a boundary parsing vulnerability that allows attackers to smuggle additional archive entries by exploiting inconsistent PAX/ustar header handling. When processing archives with PAX-extended headers containing size overrides, the parser incorrectly advances stream position based on ustar header size (often zero) instead of the PAX-specified size, causing it to interpret file content as legitimate tar headers.\n\nThis vulnerability was disclosed to multiple Rust tar parsers, all derived from the original `async-tar` fork of `tar-rs`.\n\n## Details\n\n### Vulnerability Description\n\nThe vulnerability stems from inconsistent handling of PAX extended headers versus ustar headers when determining file data boundaries. Specifically:\n\n1. **PAX header** correctly specifies the file size (e.g., `size=1048576`)\n2. **ustar header** incorrectly specifies zero size (`size=000000000000`)\n3. **tokio-tar** advances the stream position based on the ustar size (0 bytes)\n4. **Inner content** is then interpreted as legitimate outer archive entries\n\n### Attack Mechanism\n\nWhen a TAR file contains:\n\n- An outer entry with PAX `size=N` but ustar `size=0`\n- File data that begins with valid TAR header structures\n- The parser treats inner content as additional outer entries\n\nThis creates a **header/data desynchronization** where the parser's position becomes misaligned with actual file boundaries.\n\n### Root Cause\n\n```rust\n// Vulnerable: Uses ustar size instead of PAX override\nlet file_size = header.size(); // Returns 0 from ustar field\nlet next_pos = current_pos + 512 + pad_to_512(file_size); // Advances 0 bytes\n\n// Fixed: Apply PAX overrides before position calculation\nlet mut file_size = header.size();\nif let Some(pax_size) = pending_pax.get(\"size\") {\n file_size = pax_size.parse().unwrap();\n}\nlet next_pos = current_pos + 512 + pad_to_512(file_size); // Correct advance\n\n```\n\n## Impact\n\nThe impact of this vulnerability depends on where `astral-tokio-tar` is used, and whether it is used to extract untrusted tar archives. If used to extract untrusted inputs, it may result in unexpected attacker-controlled access to the filesystem, in turn potential resulting in arbitrary code execution or credential exfiltration.\n\nSee [**GHSA-w476-p2h3-79g9**](https://github.com/astral-sh/uv/security/advisories/GHSA-w476-p2h3-79g9) for how this vulnerability affects `uv`, `astral-tokio-tar`'s primary downstream user. Observe that **unlike** this advisory,` uv`'s advisory is considered **low severity** due to overlap with intentional existing capabilities in source distributions. \n\n## Workarounds\n\nUsers are advised to upgrade to version 0.5.6 or newer to address this advisory.\n\nThere is no workaround other than upgrading.\n\n## Timeline\n\n| Date | Event |\n| --- | --- |\n| Aug 21, 2025 | Vulnerability discovered by Edera Security Team |\n| Aug 21, 2025 | Initial analysis and PoC confirmed |\n| Aug 22, 2025 | Maintainers notified (privately) |\n| Aug 25, 2025 | Private patch and test suite shared |\n| Oct 7, 2025 | Text freeze for GHSA |\n| Oct 21, 2025 | Coordinated public disclosure and patched releases |\n\n## Credits\n\n- **Discovered by:** Steven Noonan (Edera) and Alex Zenla (Edera)\n- **Coordinated disclosure:** Ann Wallace (Edera)",
![advisory-database[bot]](https://avatars.githubusercontent.com/in/21409?v=4&size=40){kind=avatar}
0 commit comments