astral-tokio-tar

Impact

Versions of astral-tokio-tar prior to 0.6.2 contain a PAX header interpretation bug that allows manipulated entries to be made selectively visible or invisible during extraction with astral-tokio-tar versus other tar implementations. An attacker could use this differential to smuggle unexpected files onto a victim's filesystem.

Details

When a tar stream contains multiple "header" entries prior to a file entry, astral-tokio-tar 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, 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 astral-tokio-tar applies the PAX header's size extension to the next header in sequence, effectively desynchronizing the stream and enabling astral-tokio-tar specific skippage/extraction of members. In other words, a file can be contrived to extract differently on astral-tokio-tar than on other tar parsers.

Patches

Versions 0.6.2 and newer of astral-tokio-tar address this differential.

Workarounds

Users are advised to upgrade to version 0.6.1 or newer to address this advisory.

There is no workaround other than upgrading. Users should experience no breaking changes as a result of the upgrade.

Resources

• GHSA-j5gw-2vrg-8fgx is a similar PAX desynchronization bug
• GHSA-fp55-jw48-c537 is another similar PAX desynchronization bug

Impact

Versions of astral-tokio-tar prior to 0.6.2 contain a PAX header interpretation bug that allows manipulated entries to be made selectively visible or invisible during extraction with astral-tokio-tar versus other tar implementations. An attacker could use this differential to smuggle unexpected files onto a victim's filesystem.

Details

When a tar stream contains multiple "header" entries prior to a file entry, astral-tokio-tar 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, 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 astral-tokio-tar applies the PAX header's size extension to the next header in sequence, effectively desynchronizing the stream and enabling astral-tokio-tar specific skippage/extraction of members. In other words, a file can be contrived to extract differently on astral-tokio-tar than on other tar parsers.

Patches

Versions 0.6.2 and newer of astral-tokio-tar address this differential.

Workarounds

Users are advised to upgrade to version 0.6.1 or newer to address this advisory.

There is no workaround other than upgrading. Users should experience no breaking changes as a result of the upgrade.

Resources

• GHSA-j5gw-2vrg-8fgx is a similar PAX desynchronization bug
• GHSA-fp55-jw48-c537 is another similar PAX desynchronization bug

Impact

In versions 0.6.0 and earlier of astral-tokio-tar, the unpack_in API could inadvertently modify the permissions of external (i.e. non-archive) directories outside of the archive. An attacker could use this to contrite a tar archive that maliciously changes directory permissions outside of its intended hierarchy. This flaw only affects directories; individual file permissions cannot be modified via it.

See GHSA-j4xf-2g29-59ph for the equivalent flaw in the tar crate.

Patches

Versions 0.6.1 and newer of astral-tokio-tar use fs::symlink_metdata rather than fs::metadata, avoiding the traversal.

Workarounds

Users are advised to upgrade to version 0.6.1 or newer to address this advisory.

Users should experience no breaking changes as a result of the patch above.

Resources

• GHSA-j4xf-2g29-59ph for the original tar vulnerability

Attribution

• Reporter: Adam Harvey (@lawngnome)

Impact

Versions of astral-tokio-tar prior to 0.6.1 contain a PAX header interpretation bug that allows manipulated entries to be made selectively visible or invisible during extraction with astral-tokio-tar versus other tar implementations. An attacker could use this differential to smuggle unexpected files onto a victim's filesystem.

See GHSA-j5gw-2vrg-8fgx for a similar desynchronization bug in astral-tokio-tar.

Patches

Versions 0.6.1 and newer of astral-tokio-tar address this differential.

Workarounds

Users are advised to upgrade to version 0.6.1 or newer to address this advisory.

There is no workaround other than upgrading. Users should experience no breaking changes as a result of the upgrade.

Resources

• GHSA-j5gw-2vrg-8fgx is a similar PAX desynchronization bug

Attribution

• Reporter: Adam Harvey (@lawngnome)

Impact

Versions of astral-tokio-tar prior to 0.6.2 contain a PAX header interpretation bug that allows manipulated entries to be made selectively visible or invisible during extraction with astral-tokio-tar versus other tar implementations. An attacker could use this differential to smuggle unexpected files onto a victim's filesystem.

Details

When a tar stream contains multiple "header" entries prior to a file entry, astral-tokio-tar 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, 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 astral-tokio-tar applies the PAX header's size extension to the next header in sequence, effectively desynchronizing the stream and enabling astral-tokio-tar specific skippage/extraction of members. In other words, a file can be contrived to extract differently on astral-tokio-tar than on other tar parsers.

Patches

Versions 0.6.2 and newer of astral-tokio-tar address this differential.

Workarounds

Users are advised to upgrade to version 0.6.1 or newer to address this advisory.

There is no workaround other than upgrading. Users should experience no breaking changes as a result of the upgrade.

Resources

• GHSA-j5gw-2vrg-8fgx is a similar PAX desynchronization bug
• GHSA-fp55-jw48-c537 is another similar PAX desynchronization bug

Impact

In versions 0.6.0 and earlier of astral-tokio-tar, the unpack_in API could inadvertently modify the permissions of external (i.e. non-archive) directories outside of the archive. An attacker could use this to contrite a tar archive that maliciously changes directory permissions outside of its intended hierarchy. This flaw only affects directories; individual file permissions cannot be modified via it.

See GHSA-j4xf-2g29-59ph for the equivalent flaw in the tar crate.

Patches

Versions 0.6.1 and newer of astral-tokio-tar use fs::symlink_metdata rather than fs::metadata, avoiding the traversal.

Workarounds

Users are advised to upgrade to version 0.6.1 or newer to address this advisory.

Users should experience no breaking changes as a result of the patch above.

Resources

• GHSA-j4xf-2g29-59ph for the original tar vulnerability

Attribution

• Reporter: Adam Harvey (@lawngnome)

Impact

Versions of astral-tokio-tar prior to 0.6.1 contain a PAX header interpretation bug that allows manipulated entries to be made selectively visible or invisible during extraction with astral-tokio-tar versus other tar implementations. An attacker could use this differential to smuggle unexpected files onto a victim's filesystem.

See GHSA-j5gw-2vrg-8fgx for a similar desynchronization bug in astral-tokio-tar.

Patches

Versions 0.6.1 and newer of astral-tokio-tar address this differential.

Workarounds

Users are advised to upgrade to version 0.6.1 or newer to address this advisory.

There is no workaround other than upgrading. Users should experience no breaking changes as a result of the upgrade.

Resources

• GHSA-j5gw-2vrg-8fgx is a similar PAX desynchronization bug

Attribution

• Reporter: Adam Harvey (@lawngnome)

Impact

Versions of astral-tokio-tar prior to 0.6.2 contain a PAX header interpretation bug that allows manipulated entries to be made selectively visible or invisible during extraction with astral-tokio-tar versus other tar implementations. An attacker could use this differential to smuggle unexpected files onto a victim's filesystem.

Details

When a tar stream contains multiple "header" entries prior to a file entry, astral-tokio-tar 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, 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 astral-tokio-tar applies the PAX header's size extension to the next header in sequence, effectively desynchronizing the stream and enabling astral-tokio-tar specific skippage/extraction of members. In other words, a file can be contrived to extract differently on astral-tokio-tar than on other tar parsers.

Patches

Versions 0.6.2 and newer of astral-tokio-tar address this differential.

Workarounds

Users are advised to upgrade to version 0.6.1 or newer to address this advisory.

There is no workaround other than upgrading. Users should experience no breaking changes as a result of the upgrade.

Resources

• GHSA-j5gw-2vrg-8fgx is a similar PAX desynchronization bug
• GHSA-fp55-jw48-c537 is another similar PAX desynchronization bug

Impact

In versions 0.6.0 and earlier of astral-tokio-tar, the unpack_in API could inadvertently modify the permissions of external (i.e. non-archive) directories outside of the archive. An attacker could use this to contrite a tar archive that maliciously changes directory permissions outside of its intended hierarchy. This flaw only affects directories; individual file permissions cannot be modified via it.

See GHSA-j4xf-2g29-59ph for the equivalent flaw in the tar crate.

Patches

Versions 0.6.1 and newer of astral-tokio-tar use fs::symlink_metdata rather than fs::metadata, avoiding the traversal.

Workarounds

Users are advised to upgrade to version 0.6.1 or newer to address this advisory.

Users should experience no breaking changes as a result of the patch above.

Resources

• GHSA-j4xf-2g29-59ph for the original tar vulnerability

Attribution

• Reporter: Adam Harvey (@lawngnome)

Impact

Versions of astral-tokio-tar prior to 0.6.1 contain a PAX header interpretation bug that allows manipulated entries to be made selectively visible or invisible during extraction with astral-tokio-tar versus other tar implementations. An attacker could use this differential to smuggle unexpected files onto a victim's filesystem.

See GHSA-j5gw-2vrg-8fgx for a similar desynchronization bug in astral-tokio-tar.

Patches

Versions 0.6.1 and newer of astral-tokio-tar address this differential.

Workarounds

Users are advised to upgrade to version 0.6.1 or newer to address this advisory.

There is no workaround other than upgrading. Users should experience no breaking changes as a result of the upgrade.

Resources

• GHSA-j5gw-2vrg-8fgx is a similar PAX desynchronization bug

Attribution

• Reporter: Adam Harvey (@lawngnome)

Impact

In versions 0.5.6 and earlier of astral-tokio-tar, malformed PAX extensions were silently skipped when parsing tar archives. This silent skipping (rather than rejection) of invalid PAX extensions could be used as a building block for a parser differential, for example by having astral-tokio-tar silently skip a malformed GNU “long link” extension so that a subsequent parser would misinterpret the extension.

In practice, exploiting this behavior in astral-tokio-tar requires a secondary misbehaving tar parser, i.e. one that insufficiently validates malformed PAX extensions and interprets them rather than skipping or erroring on them. Consequently this advisory is considered low-severity within astral-tokio-tar itself, as it requires a separate vulnerability against any unrelated tar parser.

Patches

Versions 0.6.0 and newer of astral-tokio-tar reject invalid PAX extensions, rather than silently skipping them.

Workarounds

Users are advised to upgrade to version 0.6.0 or newer to address this advisory.

Most users should experience no breaking changes as a result of the patch above. Some users who attempt to extract poorly constructed tar files may experience errors; users should re-construct their tar files with a conforming tar parser.

Attribution

• Sergei Zimmerman (@xokdvium)

Impact

Versions of astral-tokio-tar prior to 0.6.2 contain a PAX header interpretation bug that allows manipulated entries to be made selectively visible or invisible during extraction with astral-tokio-tar versus other tar implementations. An attacker could use this differential to smuggle unexpected files onto a victim's filesystem.

Details

When a tar stream contains multiple "header" entries prior to a file entry, astral-tokio-tar 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, 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 astral-tokio-tar applies the PAX header's size extension to the next header in sequence, effectively desynchronizing the stream and enabling astral-tokio-tar specific skippage/extraction of members. In other words, a file can be contrived to extract differently on astral-tokio-tar than on other tar parsers.

Patches

Versions 0.6.2 and newer of astral-tokio-tar address this differential.

Workarounds

Users are advised to upgrade to version 0.6.1 or newer to address this advisory.

There is no workaround other than upgrading. Users should experience no breaking changes as a result of the upgrade.

Resources

• GHSA-j5gw-2vrg-8fgx is a similar PAX desynchronization bug
• GHSA-fp55-jw48-c537 is another similar PAX desynchronization bug

Impact

In versions 0.6.0 and earlier of astral-tokio-tar, the unpack_in API could inadvertently modify the permissions of external (i.e. non-archive) directories outside of the archive. An attacker could use this to contrite a tar archive that maliciously changes directory permissions outside of its intended hierarchy. This flaw only affects directories; individual file permissions cannot be modified via it.

See GHSA-j4xf-2g29-59ph for the equivalent flaw in the tar crate.

Patches

Versions 0.6.1 and newer of astral-tokio-tar use fs::symlink_metdata rather than fs::metadata, avoiding the traversal.

Workarounds

Users are advised to upgrade to version 0.6.1 or newer to address this advisory.

Users should experience no breaking changes as a result of the patch above.

Resources

• GHSA-j4xf-2g29-59ph for the original tar vulnerability

Attribution

• Reporter: Adam Harvey (@lawngnome)

Impact

Versions of astral-tokio-tar prior to 0.6.1 contain a PAX header interpretation bug that allows manipulated entries to be made selectively visible or invisible during extraction with astral-tokio-tar versus other tar implementations. An attacker could use this differential to smuggle unexpected files onto a victim's filesystem.

See GHSA-j5gw-2vrg-8fgx for a similar desynchronization bug in astral-tokio-tar.

Patches

Versions 0.6.1 and newer of astral-tokio-tar address this differential.

Workarounds

Users are advised to upgrade to version 0.6.1 or newer to address this advisory.

There is no workaround other than upgrading. Users should experience no breaking changes as a result of the upgrade.

Resources

• GHSA-j5gw-2vrg-8fgx is a similar PAX desynchronization bug

Attribution

• Reporter: Adam Harvey (@lawngnome)

Impact

In versions 0.5.6 and earlier of astral-tokio-tar, malformed PAX extensions were silently skipped when parsing tar archives. This silent skipping (rather than rejection) of invalid PAX extensions could be used as a building block for a parser differential, for example by having astral-tokio-tar silently skip a malformed GNU “long link” extension so that a subsequent parser would misinterpret the extension.

In practice, exploiting this behavior in astral-tokio-tar requires a secondary misbehaving tar parser, i.e. one that insufficiently validates malformed PAX extensions and interprets them rather than skipping or erroring on them. Consequently this advisory is considered low-severity within astral-tokio-tar itself, as it requires a separate vulnerability against any unrelated tar parser.

Patches

Versions 0.6.0 and newer of astral-tokio-tar reject invalid PAX extensions, rather than silently skipping them.

Workarounds

Users are advised to upgrade to version 0.6.0 or newer to address this advisory.

Most users should experience no breaking changes as a result of the patch above. Some users who attempt to extract poorly constructed tar files may experience errors; users should re-construct their tar files with a conforming tar parser.

Attribution

• Sergei Zimmerman (@xokdvium)

Summary

Versions 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.

This vulnerability was disclosed to multiple Rust tar parsers, all derived from the original async-tar fork of tar-rs.

Details

Vulnerability Description

The vulnerability stems from inconsistent handling of PAX extended headers versus ustar headers when determining file data boundaries. Specifically:

1. PAX header correctly specifies the file size (e.g., size=1048576)
2. ustar header incorrectly specifies zero size (size=000000000000)
3. tokio-tar advances the stream position based on the ustar size (0 bytes)
4. Inner content is then interpreted as legitimate outer archive entries

Attack Mechanism

When a TAR file contains:

• An outer entry with PAX size=N but ustar size=0
• File data that begins with valid TAR header structures
• The parser treats inner content as additional outer entries

This creates a header/data desynchronization where the parser's position becomes misaligned with actual file boundaries.

Root Cause

// Vulnerable: Uses ustar size instead of PAX override
let file_size = header.size(); // Returns 0 from ustar field
let next_pos = current_pos + 512 + pad_to_512(file_size); // Advances 0 bytes

// Fixed: Apply PAX overrides before position calculation
let mut file_size = header.size();
if let Some(pax_size) = pending_pax.get("size") {
    file_size = pax_size.parse().unwrap();
}
let next_pos = current_pos + 512 + pad_to_512(file_size); // Correct advance

Impact

The 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.

See 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.

Workarounds

Users are advised to upgrade to version 0.5.6 or newer to address this advisory.

There is no workaround other than upgrading.

Timeline

| Date | Event | | --- | --- | | Aug 21, 2025 | Vulnerability discovered by Edera Security Team | | Aug 21, 2025 | Initial analysis and PoC confirmed | | Aug 22, 2025 | Maintainers notified (privately) | | Aug 25, 2025 | Private patch and test suite shared | | Oct 7, 2025 | Text freeze for GHSA | | Oct 21, 2025 | Coordinated public disclosure and patched releases |

Credits

• Discovered by: Steven Noonan (Edera) and Alex Zenla (Edera)
• Coordinated disclosure: Ann Wallace (Edera)

Impact

Versions of astral-tokio-tar prior to 0.6.2 contain a PAX header interpretation bug that allows manipulated entries to be made selectively visible or invisible during extraction with astral-tokio-tar versus other tar implementations. An attacker could use this differential to smuggle unexpected files onto a victim's filesystem.

Details

When a tar stream contains multiple "header" entries prior to a file entry, astral-tokio-tar 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, 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 astral-tokio-tar applies the PAX header's size extension to the next header in sequence, effectively desynchronizing the stream and enabling astral-tokio-tar specific skippage/extraction of members. In other words, a file can be contrived to extract differently on astral-tokio-tar than on other tar parsers.

Patches

Versions 0.6.2 and newer of astral-tokio-tar address this differential.

Workarounds

Users are advised to upgrade to version 0.6.1 or newer to address this advisory.

There is no workaround other than upgrading. Users should experience no breaking changes as a result of the upgrade.

Resources

• GHSA-j5gw-2vrg-8fgx is a similar PAX desynchronization bug
• GHSA-fp55-jw48-c537 is another similar PAX desynchronization bug

Impact

In versions 0.6.0 and earlier of astral-tokio-tar, the unpack_in API could inadvertently modify the permissions of external (i.e. non-archive) directories outside of the archive. An attacker could use this to contrite a tar archive that maliciously changes directory permissions outside of its intended hierarchy. This flaw only affects directories; individual file permissions cannot be modified via it.

See GHSA-j4xf-2g29-59ph for the equivalent flaw in the tar crate.

Patches

Versions 0.6.1 and newer of astral-tokio-tar use fs::symlink_metdata rather than fs::metadata, avoiding the traversal.

Workarounds

Users are advised to upgrade to version 0.6.1 or newer to address this advisory.

Users should experience no breaking changes as a result of the patch above.

Resources

• GHSA-j4xf-2g29-59ph for the original tar vulnerability

Attribution

• Reporter: Adam Harvey (@lawngnome)

Impact

Versions of astral-tokio-tar prior to 0.6.1 contain a PAX header interpretation bug that allows manipulated entries to be made selectively visible or invisible during extraction with astral-tokio-tar versus other tar implementations. An attacker could use this differential to smuggle unexpected files onto a victim's filesystem.

See GHSA-j5gw-2vrg-8fgx for a similar desynchronization bug in astral-tokio-tar.

Patches

Versions 0.6.1 and newer of astral-tokio-tar address this differential.

Workarounds

Users are advised to upgrade to version 0.6.1 or newer to address this advisory.

There is no workaround other than upgrading. Users should experience no breaking changes as a result of the upgrade.

Resources

• GHSA-j5gw-2vrg-8fgx is a similar PAX desynchronization bug

Attribution

• Reporter: Adam Harvey (@lawngnome)

Impact

In versions 0.5.6 and earlier of astral-tokio-tar, malformed PAX extensions were silently skipped when parsing tar archives. This silent skipping (rather than rejection) of invalid PAX extensions could be used as a building block for a parser differential, for example by having astral-tokio-tar silently skip a malformed GNU “long link” extension so that a subsequent parser would misinterpret the extension.

In practice, exploiting this behavior in astral-tokio-tar requires a secondary misbehaving tar parser, i.e. one that insufficiently validates malformed PAX extensions and interprets them rather than skipping or erroring on them. Consequently this advisory is considered low-severity within astral-tokio-tar itself, as it requires a separate vulnerability against any unrelated tar parser.

Patches

Versions 0.6.0 and newer of astral-tokio-tar reject invalid PAX extensions, rather than silently skipping them.

Workarounds

Users are advised to upgrade to version 0.6.0 or newer to address this advisory.

Most users should experience no breaking changes as a result of the patch above. Some users who attempt to extract poorly constructed tar files may experience errors; users should re-construct their tar files with a conforming tar parser.

Attribution

• Sergei Zimmerman (@xokdvium)

Summary

Versions 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.

This vulnerability was disclosed to multiple Rust tar parsers, all derived from the original async-tar fork of tar-rs.

Details

Vulnerability Description

The vulnerability stems from inconsistent handling of PAX extended headers versus ustar headers when determining file data boundaries. Specifically:

1. PAX header correctly specifies the file size (e.g., size=1048576)
2. ustar header incorrectly specifies zero size (size=000000000000)
3. tokio-tar advances the stream position based on the ustar size (0 bytes)
4. Inner content is then interpreted as legitimate outer archive entries

Attack Mechanism

When a TAR file contains:

• An outer entry with PAX size=N but ustar size=0
• File data that begins with valid TAR header structures
• The parser treats inner content as additional outer entries

This creates a header/data desynchronization where the parser's position becomes misaligned with actual file boundaries.

Root Cause

// Vulnerable: Uses ustar size instead of PAX override
let file_size = header.size(); // Returns 0 from ustar field
let next_pos = current_pos + 512 + pad_to_512(file_size); // Advances 0 bytes

// Fixed: Apply PAX overrides before position calculation
let mut file_size = header.size();
if let Some(pax_size) = pending_pax.get("size") {
    file_size = pax_size.parse().unwrap();
}
let next_pos = current_pos + 512 + pad_to_512(file_size); // Correct advance

Impact

The 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.

See 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.

Workarounds

Users are advised to upgrade to version 0.5.6 or newer to address this advisory.

There is no workaround other than upgrading.

Timeline

| Date | Event | | --- | --- | | Aug 21, 2025 | Vulnerability discovered by Edera Security Team | | Aug 21, 2025 | Initial analysis and PoC confirmed | | Aug 22, 2025 | Maintainers notified (privately) | | Aug 25, 2025 | Private patch and test suite shared | | Oct 7, 2025 | Text freeze for GHSA | | Oct 21, 2025 | Coordinated public disclosure and patched releases |

Credits

• Discovered by: Steven Noonan (Edera) and Alex Zenla (Edera)
• Coordinated disclosure: Ann Wallace (Edera)

Impact

Versions of astral-tokio-tar prior to 0.6.2 contain a PAX header interpretation bug that allows manipulated entries to be made selectively visible or invisible during extraction with astral-tokio-tar versus other tar implementations. An attacker could use this differential to smuggle unexpected files onto a victim's filesystem.

Details

When a tar stream contains multiple "header" entries prior to a file entry, astral-tokio-tar 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, 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 astral-tokio-tar applies the PAX header's size extension to the next header in sequence, effectively desynchronizing the stream and enabling astral-tokio-tar specific skippage/extraction of members. In other words, a file can be contrived to extract differently on astral-tokio-tar than on other tar parsers.

Patches

Versions 0.6.2 and newer of astral-tokio-tar address this differential.

Workarounds

Users are advised to upgrade to version 0.6.1 or newer to address this advisory.

There is no workaround other than upgrading. Users should experience no breaking changes as a result of the upgrade.

Resources

• GHSA-j5gw-2vrg-8fgx is a similar PAX desynchronization bug
• GHSA-fp55-jw48-c537 is another similar PAX desynchronization bug

Impact

In versions 0.6.0 and earlier of astral-tokio-tar, the unpack_in API could inadvertently modify the permissions of external (i.e. non-archive) directories outside of the archive. An attacker could use this to contrite a tar archive that maliciously changes directory permissions outside of its intended hierarchy. This flaw only affects directories; individual file permissions cannot be modified via it.

See GHSA-j4xf-2g29-59ph for the equivalent flaw in the tar crate.

Patches

Versions 0.6.1 and newer of astral-tokio-tar use fs::symlink_metdata rather than fs::metadata, avoiding the traversal.

Workarounds

Users are advised to upgrade to version 0.6.1 or newer to address this advisory.

Users should experience no breaking changes as a result of the patch above.

Resources

• GHSA-j4xf-2g29-59ph for the original tar vulnerability

Attribution

• Reporter: Adam Harvey (@lawngnome)

Impact

Versions of astral-tokio-tar prior to 0.6.1 contain a PAX header interpretation bug that allows manipulated entries to be made selectively visible or invisible during extraction with astral-tokio-tar versus other tar implementations. An attacker could use this differential to smuggle unexpected files onto a victim's filesystem.

See GHSA-j5gw-2vrg-8fgx for a similar desynchronization bug in astral-tokio-tar.

Patches

Versions 0.6.1 and newer of astral-tokio-tar address this differential.

Workarounds

Users are advised to upgrade to version 0.6.1 or newer to address this advisory.

There is no workaround other than upgrading. Users should experience no breaking changes as a result of the upgrade.

Resources

• GHSA-j5gw-2vrg-8fgx is a similar PAX desynchronization bug

Attribution

• Reporter: Adam Harvey (@lawngnome)

Impact

In versions 0.5.6 and earlier of astral-tokio-tar, malformed PAX extensions were silently skipped when parsing tar archives. This silent skipping (rather than rejection) of invalid PAX extensions could be used as a building block for a parser differential, for example by having astral-tokio-tar silently skip a malformed GNU “long link” extension so that a subsequent parser would misinterpret the extension.

In practice, exploiting this behavior in astral-tokio-tar requires a secondary misbehaving tar parser, i.e. one that insufficiently validates malformed PAX extensions and interprets them rather than skipping or erroring on them. Consequently this advisory is considered low-severity within astral-tokio-tar itself, as it requires a separate vulnerability against any unrelated tar parser.

Patches

Versions 0.6.0 and newer of astral-tokio-tar reject invalid PAX extensions, rather than silently skipping them.

Workarounds

Users are advised to upgrade to version 0.6.0 or newer to address this advisory.

Most users should experience no breaking changes as a result of the patch above. Some users who attempt to extract poorly constructed tar files may experience errors; users should re-construct their tar files with a conforming tar parser.

Attribution

• Sergei Zimmerman (@xokdvium)

Summary

Versions 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.

This vulnerability was disclosed to multiple Rust tar parsers, all derived from the original async-tar fork of tar-rs.

Details

Vulnerability Description

The vulnerability stems from inconsistent handling of PAX extended headers versus ustar headers when determining file data boundaries. Specifically:

1. PAX header correctly specifies the file size (e.g., size=1048576)
2. ustar header incorrectly specifies zero size (size=000000000000)
3. tokio-tar advances the stream position based on the ustar size (0 bytes)
4. Inner content is then interpreted as legitimate outer archive entries

Attack Mechanism

When a TAR file contains:

• An outer entry with PAX size=N but ustar size=0
• File data that begins with valid TAR header structures
• The parser treats inner content as additional outer entries

This creates a header/data desynchronization where the parser's position becomes misaligned with actual file boundaries.

Root Cause

// Vulnerable: Uses ustar size instead of PAX override
let file_size = header.size(); // Returns 0 from ustar field
let next_pos = current_pos + 512 + pad_to_512(file_size); // Advances 0 bytes

// Fixed: Apply PAX overrides before position calculation
let mut file_size = header.size();
if let Some(pax_size) = pending_pax.get("size") {
    file_size = pax_size.parse().unwrap();
}
let next_pos = current_pos + 512 + pad_to_512(file_size); // Correct advance

Impact

The 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.

See 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.

Workarounds

Users are advised to upgrade to version 0.5.6 or newer to address this advisory.

There is no workaround other than upgrading.

Timeline

| Date | Event | | --- | --- | | Aug 21, 2025 | Vulnerability discovered by Edera Security Team | | Aug 21, 2025 | Initial analysis and PoC confirmed | | Aug 22, 2025 | Maintainers notified (privately) | | Aug 25, 2025 | Private patch and test suite shared | | Oct 7, 2025 | Text freeze for GHSA | | Oct 21, 2025 | Coordinated public disclosure and patched releases |

Credits

• Discovered by: Steven Noonan (Edera) and Alex Zenla (Edera)
• Coordinated disclosure: Ann Wallace (Edera)

Impact

In versions 0.5.3 and earlier of astral-tokio-tar, tar archives may extract outside of their intended destination directory when using the Entry::unpack_in_raw API. Additionally, the Entry::allow_external_symlinks control (which defaults to true) could be bypassed via a pair of symlinks that individually point within the destination but combine to point outside of it.

These behaviors could be used individually or combined to bypass the intended security control of limiting extraction to the given directory. This in turn would allow an attacker with a malicious tar archive to perform an arbitrary file write and potentially pivot into code execution (e.g. by overwriting a file that the user or system then executes or uses to execute code).

The impact of this vulnerability for downstream API users of this crate is high, per above. However, for this crate's main downstream user (uv), the impact of this vulnerability is low due to its overlap with equivalent user capabilities in source distributions. See GHSA-7j9j-68r2-f35q for additional details.

Patches

Versions 0.5.4 and newer of astral-tokio-tar address the vulnerability above. Users should upgrade to 0.5.4 or newer.

Workarounds

Users are advised to upgrade to version 0.5.4 or newer to address this advisory.

There is no workaround other than upgrading.

References

• See GHSA-7j9j-68r2-f35q 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.
• This vulnerability is similar to (but not related in code) to CVE-2025-4138 and CVE-2025-4517, which concern Python's tarfile module.

Impact

Versions of astral-tokio-tar prior to 0.6.2 contain a PAX header interpretation bug that allows manipulated entries to be made selectively visible or invisible during extraction with astral-tokio-tar versus other tar implementations. An attacker could use this differential to smuggle unexpected files onto a victim's filesystem.

Details

When a tar stream contains multiple "header" entries prior to a file entry, astral-tokio-tar 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, 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 astral-tokio-tar applies the PAX header's size extension to the next header in sequence, effectively desynchronizing the stream and enabling astral-tokio-tar specific skippage/extraction of members. In other words, a file can be contrived to extract differently on astral-tokio-tar than on other tar parsers.

Patches

Versions 0.6.2 and newer of astral-tokio-tar address this differential.

Workarounds

Users are advised to upgrade to version 0.6.1 or newer to address this advisory.

There is no workaround other than upgrading. Users should experience no breaking changes as a result of the upgrade.

Resources

• GHSA-j5gw-2vrg-8fgx is a similar PAX desynchronization bug
• GHSA-fp55-jw48-c537 is another similar PAX desynchronization bug

Impact

In versions 0.6.0 and earlier of astral-tokio-tar, the unpack_in API could inadvertently modify the permissions of external (i.e. non-archive) directories outside of the archive. An attacker could use this to contrite a tar archive that maliciously changes directory permissions outside of its intended hierarchy. This flaw only affects directories; individual file permissions cannot be modified via it.

See GHSA-j4xf-2g29-59ph for the equivalent flaw in the tar crate.

Patches

Versions 0.6.1 and newer of astral-tokio-tar use fs::symlink_metdata rather than fs::metadata, avoiding the traversal.

Workarounds

Users are advised to upgrade to version 0.6.1 or newer to address this advisory.

Users should experience no breaking changes as a result of the patch above.

Resources

• GHSA-j4xf-2g29-59ph for the original tar vulnerability

Attribution

• Reporter: Adam Harvey (@lawngnome)

Impact

Versions of astral-tokio-tar prior to 0.6.1 contain a PAX header interpretation bug that allows manipulated entries to be made selectively visible or invisible during extraction with astral-tokio-tar versus other tar implementations. An attacker could use this differential to smuggle unexpected files onto a victim's filesystem.

See GHSA-j5gw-2vrg-8fgx for a similar desynchronization bug in astral-tokio-tar.

Patches

Versions 0.6.1 and newer of astral-tokio-tar address this differential.

Workarounds

Users are advised to upgrade to version 0.6.1 or newer to address this advisory.

There is no workaround other than upgrading. Users should experience no breaking changes as a result of the upgrade.

Resources

• GHSA-j5gw-2vrg-8fgx is a similar PAX desynchronization bug

Attribution

• Reporter: Adam Harvey (@lawngnome)

Impact

In versions 0.5.6 and earlier of astral-tokio-tar, malformed PAX extensions were silently skipped when parsing tar archives. This silent skipping (rather than rejection) of invalid PAX extensions could be used as a building block for a parser differential, for example by having astral-tokio-tar silently skip a malformed GNU “long link” extension so that a subsequent parser would misinterpret the extension.

In practice, exploiting this behavior in astral-tokio-tar requires a secondary misbehaving tar parser, i.e. one that insufficiently validates malformed PAX extensions and interprets them rather than skipping or erroring on them. Consequently this advisory is considered low-severity within astral-tokio-tar itself, as it requires a separate vulnerability against any unrelated tar parser.

Patches

Versions 0.6.0 and newer of astral-tokio-tar reject invalid PAX extensions, rather than silently skipping them.

Workarounds

Users are advised to upgrade to version 0.6.0 or newer to address this advisory.

Most users should experience no breaking changes as a result of the patch above. Some users who attempt to extract poorly constructed tar files may experience errors; users should re-construct their tar files with a conforming tar parser.

Attribution

• Sergei Zimmerman (@xokdvium)

Summary

Versions 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.

This vulnerability was disclosed to multiple Rust tar parsers, all derived from the original async-tar fork of tar-rs.

Details

Vulnerability Description

The vulnerability stems from inconsistent handling of PAX extended headers versus ustar headers when determining file data boundaries. Specifically:

1. PAX header correctly specifies the file size (e.g., size=1048576)
2. ustar header incorrectly specifies zero size (size=000000000000)
3. tokio-tar advances the stream position based on the ustar size (0 bytes)
4. Inner content is then interpreted as legitimate outer archive entries

Attack Mechanism

When a TAR file contains:

• An outer entry with PAX size=N but ustar size=0
• File data that begins with valid TAR header structures
• The parser treats inner content as additional outer entries

This creates a header/data desynchronization where the parser's position becomes misaligned with actual file boundaries.

Root Cause

// Vulnerable: Uses ustar size instead of PAX override
let file_size = header.size(); // Returns 0 from ustar field
let next_pos = current_pos + 512 + pad_to_512(file_size); // Advances 0 bytes

// Fixed: Apply PAX overrides before position calculation
let mut file_size = header.size();
if let Some(pax_size) = pending_pax.get("size") {
    file_size = pax_size.parse().unwrap();
}
let next_pos = current_pos + 512 + pad_to_512(file_size); // Correct advance

Impact

The 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.

See 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.

Workarounds

Users are advised to upgrade to version 0.5.6 or newer to address this advisory.

There is no workaround other than upgrading.

Timeline

| Date | Event | | --- | --- | | Aug 21, 2025 | Vulnerability discovered by Edera Security Team | | Aug 21, 2025 | Initial analysis and PoC confirmed | | Aug 22, 2025 | Maintainers notified (privately) | | Aug 25, 2025 | Private patch and test suite shared | | Oct 7, 2025 | Text freeze for GHSA | | Oct 21, 2025 | Coordinated public disclosure and patched releases |

Credits

• Discovered by: Steven Noonan (Edera) and Alex Zenla (Edera)
• Coordinated disclosure: Ann Wallace (Edera)

Impact

In versions 0.5.3 and earlier of astral-tokio-tar, tar archives may extract outside of their intended destination directory when using the Entry::unpack_in_raw API. Additionally, the Entry::allow_external_symlinks control (which defaults to true) could be bypassed via a pair of symlinks that individually point within the destination but combine to point outside of it.

These behaviors could be used individually or combined to bypass the intended security control of limiting extraction to the given directory. This in turn would allow an attacker with a malicious tar archive to perform an arbitrary file write and potentially pivot into code execution (e.g. by overwriting a file that the user or system then executes or uses to execute code).

The impact of this vulnerability for downstream API users of this crate is high, per above. However, for this crate's main downstream user (uv), the impact of this vulnerability is low due to its overlap with equivalent user capabilities in source distributions. See GHSA-7j9j-68r2-f35q for additional details.

Patches

Versions 0.5.4 and newer of astral-tokio-tar address the vulnerability above. Users should upgrade to 0.5.4 or newer.

Workarounds

Users are advised to upgrade to version 0.5.4 or newer to address this advisory.

There is no workaround other than upgrading.

References

• See GHSA-7j9j-68r2-f35q 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.
• This vulnerability is similar to (but not related in code) to CVE-2025-4138 and CVE-2025-4517, which concern Python's tarfile module.

Impact

Versions of astral-tokio-tar prior to 0.6.2 contain a PAX header interpretation bug that allows manipulated entries to be made selectively visible or invisible during extraction with astral-tokio-tar versus other tar implementations. An attacker could use this differential to smuggle unexpected files onto a victim's filesystem.

Details

When a tar stream contains multiple "header" entries prior to a file entry, astral-tokio-tar 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, 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 astral-tokio-tar applies the PAX header's size extension to the next header in sequence, effectively desynchronizing the stream and enabling astral-tokio-tar specific skippage/extraction of members. In other words, a file can be contrived to extract differently on astral-tokio-tar than on other tar parsers.

Patches

Versions 0.6.2 and newer of astral-tokio-tar address this differential.

Workarounds

Users are advised to upgrade to version 0.6.1 or newer to address this advisory.

There is no workaround other than upgrading. Users should experience no breaking changes as a result of the upgrade.

Resources

• GHSA-j5gw-2vrg-8fgx is a similar PAX desynchronization bug
• GHSA-fp55-jw48-c537 is another similar PAX desynchronization bug

Impact

In versions 0.6.0 and earlier of astral-tokio-tar, the unpack_in API could inadvertently modify the permissions of external (i.e. non-archive) directories outside of the archive. An attacker could use this to contrite a tar archive that maliciously changes directory permissions outside of its intended hierarchy. This flaw only affects directories; individual file permissions cannot be modified via it.

See GHSA-j4xf-2g29-59ph for the equivalent flaw in the tar crate.

Patches

Versions 0.6.1 and newer of astral-tokio-tar use fs::symlink_metdata rather than fs::metadata, avoiding the traversal.

Workarounds

Users are advised to upgrade to version 0.6.1 or newer to address this advisory.

Users should experience no breaking changes as a result of the patch above.

Resources

• GHSA-j4xf-2g29-59ph for the original tar vulnerability

Attribution

• Reporter: Adam Harvey (@lawngnome)

Impact

Versions of astral-tokio-tar prior to 0.6.1 contain a PAX header interpretation bug that allows manipulated entries to be made selectively visible or invisible during extraction with astral-tokio-tar versus other tar implementations. An attacker could use this differential to smuggle unexpected files onto a victim's filesystem.

See GHSA-j5gw-2vrg-8fgx for a similar desynchronization bug in astral-tokio-tar.

Patches

Versions 0.6.1 and newer of astral-tokio-tar address this differential.

Workarounds

Users are advised to upgrade to version 0.6.1 or newer to address this advisory.

There is no workaround other than upgrading. Users should experience no breaking changes as a result of the upgrade.

Resources

• GHSA-j5gw-2vrg-8fgx is a similar PAX desynchronization bug

Attribution

• Reporter: Adam Harvey (@lawngnome)

Impact

In versions 0.5.6 and earlier of astral-tokio-tar, malformed PAX extensions were silently skipped when parsing tar archives. This silent skipping (rather than rejection) of invalid PAX extensions could be used as a building block for a parser differential, for example by having astral-tokio-tar silently skip a malformed GNU “long link” extension so that a subsequent parser would misinterpret the extension.

In practice, exploiting this behavior in astral-tokio-tar requires a secondary misbehaving tar parser, i.e. one that insufficiently validates malformed PAX extensions and interprets them rather than skipping or erroring on them. Consequently this advisory is considered low-severity within astral-tokio-tar itself, as it requires a separate vulnerability against any unrelated tar parser.

Patches

Versions 0.6.0 and newer of astral-tokio-tar reject invalid PAX extensions, rather than silently skipping them.

Workarounds

Users are advised to upgrade to version 0.6.0 or newer to address this advisory.

Most users should experience no breaking changes as a result of the patch above. Some users who attempt to extract poorly constructed tar files may experience errors; users should re-construct their tar files with a conforming tar parser.

Attribution

• Sergei Zimmerman (@xokdvium)

Summary

Versions 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.

This vulnerability was disclosed to multiple Rust tar parsers, all derived from the original async-tar fork of tar-rs.

Details

Vulnerability Description

The vulnerability stems from inconsistent handling of PAX extended headers versus ustar headers when determining file data boundaries. Specifically:

1. PAX header correctly specifies the file size (e.g., size=1048576)
2. ustar header incorrectly specifies zero size (size=000000000000)
3. tokio-tar advances the stream position based on the ustar size (0 bytes)
4. Inner content is then interpreted as legitimate outer archive entries

Attack Mechanism

When a TAR file contains:

• An outer entry with PAX size=N but ustar size=0
• File data that begins with valid TAR header structures
• The parser treats inner content as additional outer entries

This creates a header/data desynchronization where the parser's position becomes misaligned with actual file boundaries.

Root Cause

// Vulnerable: Uses ustar size instead of PAX override
let file_size = header.size(); // Returns 0 from ustar field
let next_pos = current_pos + 512 + pad_to_512(file_size); // Advances 0 bytes

// Fixed: Apply PAX overrides before position calculation
let mut file_size = header.size();
if let Some(pax_size) = pending_pax.get("size") {
    file_size = pax_size.parse().unwrap();
}
let next_pos = current_pos + 512 + pad_to_512(file_size); // Correct advance

Impact

The 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.

See 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.

Workarounds

Users are advised to upgrade to version 0.5.6 or newer to address this advisory.

There is no workaround other than upgrading.

Timeline

| Date | Event | | --- | --- | | Aug 21, 2025 | Vulnerability discovered by Edera Security Team | | Aug 21, 2025 | Initial analysis and PoC confirmed | | Aug 22, 2025 | Maintainers notified (privately) | | Aug 25, 2025 | Private patch and test suite shared | | Oct 7, 2025 | Text freeze for GHSA | | Oct 21, 2025 | Coordinated public disclosure and patched releases |

Credits

• Discovered by: Steven Noonan (Edera) and Alex Zenla (Edera)
• Coordinated disclosure: Ann Wallace (Edera)

Impact

In versions 0.5.3 and earlier of astral-tokio-tar, tar archives may extract outside of their intended destination directory when using the Entry::unpack_in_raw API. Additionally, the Entry::allow_external_symlinks control (which defaults to true) could be bypassed via a pair of symlinks that individually point within the destination but combine to point outside of it.

These behaviors could be used individually or combined to bypass the intended security control of limiting extraction to the given directory. This in turn would allow an attacker with a malicious tar archive to perform an arbitrary file write and potentially pivot into code execution (e.g. by overwriting a file that the user or system then executes or uses to execute code).

The impact of this vulnerability for downstream API users of this crate is high, per above. However, for this crate's main downstream user (uv), the impact of this vulnerability is low due to its overlap with equivalent user capabilities in source distributions. See GHSA-7j9j-68r2-f35q for additional details.

Patches

Versions 0.5.4 and newer of astral-tokio-tar address the vulnerability above. Users should upgrade to 0.5.4 or newer.

Workarounds

Users are advised to upgrade to version 0.5.4 or newer to address this advisory.

There is no workaround other than upgrading.

References

• See GHSA-7j9j-68r2-f35q 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.
• This vulnerability is similar to (but not related in code) to CVE-2025-4138 and CVE-2025-4517, which concern Python's tarfile module.

Impact

Versions of astral-tokio-tar prior to 0.6.2 contain a PAX header interpretation bug that allows manipulated entries to be made selectively visible or invisible during extraction with astral-tokio-tar versus other tar implementations. An attacker could use this differential to smuggle unexpected files onto a victim's filesystem.

Details

When a tar stream contains multiple "header" entries prior to a file entry, astral-tokio-tar 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, 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 astral-tokio-tar applies the PAX header's size extension to the next header in sequence, effectively desynchronizing the stream and enabling astral-tokio-tar specific skippage/extraction of members. In other words, a file can be contrived to extract differently on astral-tokio-tar than on other tar parsers.

Patches

Versions 0.6.2 and newer of astral-tokio-tar address this differential.

Workarounds

Users are advised to upgrade to version 0.6.1 or newer to address this advisory.

There is no workaround other than upgrading. Users should experience no breaking changes as a result of the upgrade.

Resources

• GHSA-j5gw-2vrg-8fgx is a similar PAX desynchronization bug
• GHSA-fp55-jw48-c537 is another similar PAX desynchronization bug

Impact

In versions 0.6.0 and earlier of astral-tokio-tar, the unpack_in API could inadvertently modify the permissions of external (i.e. non-archive) directories outside of the archive. An attacker could use this to contrite a tar archive that maliciously changes directory permissions outside of its intended hierarchy. This flaw only affects directories; individual file permissions cannot be modified via it.

See GHSA-j4xf-2g29-59ph for the equivalent flaw in the tar crate.

Patches

Versions 0.6.1 and newer of astral-tokio-tar use fs::symlink_metdata rather than fs::metadata, avoiding the traversal.

Workarounds

Users are advised to upgrade to version 0.6.1 or newer to address this advisory.

Users should experience no breaking changes as a result of the patch above.

Resources

• GHSA-j4xf-2g29-59ph for the original tar vulnerability

Attribution

• Reporter: Adam Harvey (@lawngnome)

Impact

Versions of astral-tokio-tar prior to 0.6.1 contain a PAX header interpretation bug that allows manipulated entries to be made selectively visible or invisible during extraction with astral-tokio-tar versus other tar implementations. An attacker could use this differential to smuggle unexpected files onto a victim's filesystem.

See GHSA-j5gw-2vrg-8fgx for a similar desynchronization bug in astral-tokio-tar.

Patches

Versions 0.6.1 and newer of astral-tokio-tar address this differential.

Workarounds

Users are advised to upgrade to version 0.6.1 or newer to address this advisory.

There is no workaround other than upgrading. Users should experience no breaking changes as a result of the upgrade.

Resources

• GHSA-j5gw-2vrg-8fgx is a similar PAX desynchronization bug

Attribution

• Reporter: Adam Harvey (@lawngnome)

Impact

In versions 0.5.6 and earlier of astral-tokio-tar, malformed PAX extensions were silently skipped when parsing tar archives. This silent skipping (rather than rejection) of invalid PAX extensions could be used as a building block for a parser differential, for example by having astral-tokio-tar silently skip a malformed GNU “long link” extension so that a subsequent parser would misinterpret the extension.

In practice, exploiting this behavior in astral-tokio-tar requires a secondary misbehaving tar parser, i.e. one that insufficiently validates malformed PAX extensions and interprets them rather than skipping or erroring on them. Consequently this advisory is considered low-severity within astral-tokio-tar itself, as it requires a separate vulnerability against any unrelated tar parser.

Patches

Versions 0.6.0 and newer of astral-tokio-tar reject invalid PAX extensions, rather than silently skipping them.

Workarounds

Users are advised to upgrade to version 0.6.0 or newer to address this advisory.

Most users should experience no breaking changes as a result of the patch above. Some users who attempt to extract poorly constructed tar files may experience errors; users should re-construct their tar files with a conforming tar parser.

Attribution

• Sergei Zimmerman (@xokdvium)

Summary

Versions 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.

This vulnerability was disclosed to multiple Rust tar parsers, all derived from the original async-tar fork of tar-rs.

Details

Vulnerability Description

The vulnerability stems from inconsistent handling of PAX extended headers versus ustar headers when determining file data boundaries. Specifically:

1. PAX header correctly specifies the file size (e.g., size=1048576)
2. ustar header incorrectly specifies zero size (size=000000000000)
3. tokio-tar advances the stream position based on the ustar size (0 bytes)
4. Inner content is then interpreted as legitimate outer archive entries

Attack Mechanism

When a TAR file contains:

• An outer entry with PAX size=N but ustar size=0
• File data that begins with valid TAR header structures
• The parser treats inner content as additional outer entries

This creates a header/data desynchronization where the parser's position becomes misaligned with actual file boundaries.

Root Cause

// Vulnerable: Uses ustar size instead of PAX override
let file_size = header.size(); // Returns 0 from ustar field
let next_pos = current_pos + 512 + pad_to_512(file_size); // Advances 0 bytes

// Fixed: Apply PAX overrides before position calculation
let mut file_size = header.size();
if let Some(pax_size) = pending_pax.get("size") {
    file_size = pax_size.parse().unwrap();
}
let next_pos = current_pos + 512 + pad_to_512(file_size); // Correct advance

Impact

The 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.

See 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.

Workarounds

Users are advised to upgrade to version 0.5.6 or newer to address this advisory.

There is no workaround other than upgrading.

Timeline

| Date | Event | | --- | --- | | Aug 21, 2025 | Vulnerability discovered by Edera Security Team | | Aug 21, 2025 | Initial analysis and PoC confirmed | | Aug 22, 2025 | Maintainers notified (privately) | | Aug 25, 2025 | Private patch and test suite shared | | Oct 7, 2025 | Text freeze for GHSA | | Oct 21, 2025 | Coordinated public disclosure and patched releases |

Credits

• Discovered by: Steven Noonan (Edera) and Alex Zenla (Edera)
• Coordinated disclosure: Ann Wallace (Edera)

Impact

In versions 0.5.3 and earlier of astral-tokio-tar, tar archives may extract outside of their intended destination directory when using the Entry::unpack_in_raw API. Additionally, the Entry::allow_external_symlinks control (which defaults to true) could be bypassed via a pair of symlinks that individually point within the destination but combine to point outside of it.

These behaviors could be used individually or combined to bypass the intended security control of limiting extraction to the given directory. This in turn would allow an attacker with a malicious tar archive to perform an arbitrary file write and potentially pivot into code execution (e.g. by overwriting a file that the user or system then executes or uses to execute code).

The impact of this vulnerability for downstream API users of this crate is high, per above. However, for this crate's main downstream user (uv), the impact of this vulnerability is low due to its overlap with equivalent user capabilities in source distributions. See GHSA-7j9j-68r2-f35q for additional details.

Patches

Versions 0.5.4 and newer of astral-tokio-tar address the vulnerability above. Users should upgrade to 0.5.4 or newer.

Workarounds

Users are advised to upgrade to version 0.5.4 or newer to address this advisory.

There is no workaround other than upgrading.

References

• See GHSA-7j9j-68r2-f35q 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.
• This vulnerability is similar to (but not related in code) to CVE-2025-4138 and CVE-2025-4517, which concern Python's tarfile module.