RUSTSEC-2026-0067

See a problem?
Please try reporting it to the source first.

Source

https://rustsec.org/advisories/RUSTSEC-2026-0067

Import Source

https://github.com/rustsec/advisory-db/blob/osv/crates/RUSTSEC-2026-0067.json

JSON Data

https://api.test.osv.dev/v1/vulns/RUSTSEC-2026-0067

Aliases

Published

2026-03-19T12:00:00Z

Modified

2026-03-23T09:45:14.134444Z

Severity

5.1 (Medium) CVSS_V4 - CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:A/VC:N/VI:L/VA:N/SC:N/SI:N/SA:N CVSS Calculator

Summary

`unpack_in` can chmod arbitrary directories by following symlinks

Details

In versions 0.4.44 and below of tar-rs, when unpacking a tar archive, the tar crate's unpack_dir function uses fs::metadata() to check whether a path that already exists is a directory. Because fs::metadata() follows symbolic links, a crafted tarball containing a symlink entry followed by a directory entry with the same name causes the crate to treat the symlink target as a valid existing directory — and subsequently apply chmod to it. This allows an attacker to modify the permissions of arbitrary directories outside the extraction root.

This issue has been fixed in version 0.4.45.

Database specific

{
    "license": "CC0-1.0"
}

References

Affected packages

crates.io / tar

Package

Name: tar; View open source insights on deps.dev
Purl: pkg:cargo/tar

Affected ranges

Type: SEMVER
Events: Introduced

0.0.0-0

Fixed

0.4.45

Ecosystem specific

{
    "affected_functions": null,
    "affects": {
        "functions": [
            "tar::Entry::unpack",
            "tar::Entry::unpack_in"
        ],
        "os": [],
        "arch": []
    }
}

Database specific

informational

null