Track vulnerabilities like this one.
Sign up free to get alerted when software you use is affected.
tar: PAX header can be misapplied to non-file entries
published 5 months ago
Summary
A bug in tar-rs can allow an attacker to control how files are extracted. This could lead to unexpected behavior when using tar-rs to extract files. To mitigate this, use a different tar parser or update to a version of tar-rs that fixes this issue.
What to do
- Update alexcrichton tar to version 0.4.46.
Affected software
| Ecosystem | Vendor | Product | Affected versions |
|---|---|---|---|
| crates.io | alexcrichton | tar |
< 0.4.46 Fix: upgrade to 0.4.46
|
Original advisory text
tar has a PAX header desynchronization issue
### Summary
When a tar stream contains multiple "header" entries prior to a file entry, tar-rs applies the PAX header (`x`) to the _next_ entry in the stream, regardless of type. For example, a stream of `x -> L -> file` (PAX, GNU longname, file) would result in `x`'s extensions being applied to `L` rather than to `file`.
[Per POSIX pax](https://pubs.opengroup.org/onlinepubs/9799919799/utilities/pax.html), this is incorrect: a PAX header always applies to a file entry, not any intermediary entries. See the "pax Header Block" section for the specific prescription there.
As a result of this, an attacker can contrive a tar containing a sequence of tar headers such that tar-rs applies the PAX header's `size` extension to the next header in sequence, effectively desynchronizing the stream and enabling tar-rs specific skippage/extraction of members. In other words, a file can be contrived to extract differently on tar-rs than on other tar parsers.
### PoC
[This tar](https://github.com/user-attachments/files/27141941/pax-overrides-extension-header.tar.zip) (zipped for size) demonstrates the desynchronization: with `tar tvf`:
```
% tar tvf tests/archives/pax-overrides-extension-header.tar
---------- 0 0 0 2048 Dec 31 1969 longname.txt
---------- 0 0 0 0 Dec 31 1969 file_b
```
with `tar-rs`:
```
---- pax_size_does_not_apply_to_extension_headers stdout ----
thread 'pax_size_does_not_apply_to_extension_headers' (250476889) panicked at tests/all.rs:2121:27:
called `Result::unwrap()` on an `Err` value: Custom { kind: Other, error: "numeric field was not a number: AAAAAAAA when getting cksum for AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA" }
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
```
In the above case, the PoC is not weaponized, so it jumps into the middle of an entry and subsequently fails the checksum test rather than silently continuing with attacker-controlled archive state.
### Impact
This is very similar to GHSA-j5gw-2vrg-8fgx and GHSA-fp55-jw48-c537 in impact -- an attacker can use this to extract (or not extract) files from a tar stream depending on the tar parser used, which in turn can be used to obscure the presence of malicious files.
When a tar stream contains multiple "header" entries prior to a file entry, tar-rs applies the PAX header (`x`) to the _next_ entry in the stream, regardless of type. For example, a stream of `x -> L -> file` (PAX, GNU longname, file) would result in `x`'s extensions being applied to `L` rather than to `file`.
[Per POSIX pax](https://pubs.opengroup.org/onlinepubs/9799919799/utilities/pax.html), this is incorrect: a PAX header always applies to a file entry, not any intermediary entries. See the "pax Header Block" section for the specific prescription there.
As a result of this, an attacker can contrive a tar containing a sequence of tar headers such that tar-rs applies the PAX header's `size` extension to the next header in sequence, effectively desynchronizing the stream and enabling tar-rs specific skippage/extraction of members. In other words, a file can be contrived to extract differently on tar-rs than on other tar parsers.
### PoC
[This tar](https://github.com/user-attachments/files/27141941/pax-overrides-extension-header.tar.zip) (zipped for size) demonstrates the desynchronization: with `tar tvf`:
```
% tar tvf tests/archives/pax-overrides-extension-header.tar
---------- 0 0 0 2048 Dec 31 1969 longname.txt
---------- 0 0 0 0 Dec 31 1969 file_b
```
with `tar-rs`:
```
---- pax_size_does_not_apply_to_extension_headers stdout ----
thread 'pax_size_does_not_apply_to_extension_headers' (250476889) panicked at tests/all.rs:2121:27:
called `Result::unwrap()` on an `Err` value: Custom { kind: Other, error: "numeric field was not a number: AAAAAAAA when getting cksum for AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA" }
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
```
In the above case, the PoC is not weaponized, so it jumps into the middle of an entry and subsequently fails the checksum test rather than silently continuing with attacker-controlled archive state.
### Impact
This is very similar to GHSA-j5gw-2vrg-8fgx and GHSA-fp55-jw48-c537 in impact -- an attacker can use this to extract (or not extract) files from a tar stream depending on the tar parser used, which in turn can be used to obscure the presence of malicious files.
References
- https://github.com/composefs/tar-rs/security/advisories/GHSA-3pv8-6f4r-ffg2 URL
- https://github.com/composefs/tar-rs/pull/454 URL
- https://github.com/composefs/tar-rs/commit/bab14dd84b411ac16ecb56d4f2d2f7bfb88a9... URL
- https://github.com/composefs/tar-rs Product
- https://github.com/composefs/tar-rs/releases/tag/0.4.46 URL
Type
CWE-20Improper Input Validation
CWE-843Type Confusion
Timeline
Published29 May 2026
Updated29 May 2026
First seen29 May 2026
Sources
GHSA-3pv8-6f4r-ffg2 · OSV
Track software like this
Free during beta