RUSTSEC-2026-0368: zip: `ZipArchive::extract` creates symbolic links whose attacker-controlled targets are outside the destination directory

What to do

1. See which version you have: cargo tree -i zip (it also shows which of your dependencies pulls it in).
2. Update within your version requirement: cargo update -p zip. If the fix is a newer major or minor than your requirement allows, raise it in Cargo.toml (for example zip = "9.0.0") or update the dependency that pulls it in.
3. Check again with cargo audit, or paste your Cargo.lock into our Cargo.toml checker.

Details from the advisory

In zip 9.0.0-pre2, ZipArchive::extract creates a symbolic link from an archive entry after validating only the output entry path. The link target bytes are passed directly to the platform symlink API, so a malicious archive can create an entry inside the destination that resolves to an attacker-chosen path outside it. This behavior was verified on macOS and Linux. On either platform, a subsequent application read or write through that extracted entry accesses the external target with the extracting process's permissions.

For further details see: https://github.com/zip-rs/zip2/security/advisories/GHSA-4v9h-p7m9-rh26

References

• Package: crates.io/crates/zip
• Advisory: rustsec.org/advisories/RUSTSEC-2026-0368.html

From the RustSec Advisory Database (CC0-1.0) via the OSV export, downloaded Oct 24, 2026. Severity score computed from the published CVSS vector.

Other advisories for zip

• VulnerabilityRUSTSEC-2025-0168 · 2025-03-16Incorrect path canonicalization during Archive Extraction Leading to Arbitrary File Write
• Vulnerability HighRUSTSEC-2026-0367 · 2026-10-09 Insecure Preservation of SUID/SGID Bits during ZIP Extraction Leading to Potential Privilege Escalation
• Vulnerability CriticalRUSTSEC-2026-0369 · 2026-10-10ZipStreamReader::extract() and ZipArchive::extract() apply Unix permissions through symlinks without confining the target

Full security history of zip