Open actionable advisories and recorded vendor fixes. This public package view has no inventory attached and cannot establish whether your deployment is affected. A vendor fix never resolves your finding; verify your installed version and the source guidance.
Open advisories
9 actionable advisories, newest first. Withdrawn advisories and news are excluded. Coverage is partial.
A malicious 149-byte ZIP archive can cause a denial of service in applications that enable `legacy-zip` and use `ZipArchive::extract()`. An attacker-controlled ZIP64 uncompressed size triggers a `capacity overflow` panic in the Shrink decoder in optimized builds, potentially terminating the affected process. Details When reading a Shrink-compressed entry, `ShrinkDecoder::read()` buffers the compressed input and reserves output capacity using the entry's declared uncompressed size: ```rust if !self.stream_read { self.stream_read = true; let mut compressed_bytes = Vec::new(); self.compressed_reader.read_to_end(&mut compressed_bytes)?; self.stream.reserve(self.uncompressed_size as usize); hwunshrink( &compressed_bytes, self.uncompressed_size as usize, &mut self.stream, )?; } ``` In version 8.6.0, this is located in `src/legacy/shrink.rs`. The vulnerable legacy…
Recommended action: Upgrade to 9.0.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
- Verified version: zip `9.0.0-pre3` - Affected versions: `7.2.0` and later - Precondition: The attacker knows (or can guess) the absolute path of the extraction destination The validation applied to symlinks is purely lexical. As a result, an attacker can write arbitrary files outside the extraction directory through a symlink. Exploitation requires the attacker to know (or guess) the absolute path of the destination, but this is realistic in practice: CI workspaces, `/opt/app`, a fixed Downloads path, and so on. > Impact extends further on Windows (verified on real hardware for both the separate-drive and UNC-share cases): > Because `simplified_components` discards the `Prefix` component, paths like `D:\ ` or a UNC path `\\attacker\share\ ` pass the `starts_with` check. > As a result, `outpath.push` gets replaced onto a different drive/remote share, so a single symlink is enough — no intermediate symlink chain is required. > That said, creating a…
Recommended action: Upgrade to 9.0.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
An AES-encrypted (AE-x) entry's authentication code is verified only when the reader's byte counter lands exactly on zero. If the bounded entry reader reaches the archive's actual EOF before the attacker-controlled, header-declared `compressed_size`, the counter remains positive, the HMAC is never read or compared, and the truncated, unauthenticated plaintext is returned as a clean end of stream. A zero-payload entry also returns before authentication. An attacker who does not know the password can modify an archive so chosen or modified plaintext is accepted with no error. Details `src/aes.rs:246-292`: ```rust fn read(&mut self, buf: &mut [u8]) -> io::Result { if self.data_remaining == 0 { // @audit insufficient check return Ok(0); } // get the number of bytes to read, compare as u64 to make sure we can read more than // 2^32 bytes even on 32 bit systems. let…
Recommended action: Upgrade to 9.0.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
The symbolic-link branch of `ZipArchive::extract_internal()` allocates a buffer using an attacker-declared size before reading any entry data. A 112-byte archive terminates the extracting process with `SIGABRT` through this infallible allocation. Details ```rust #[cfg(any(unix, windows))] if file.is_symlink() { let mut target = Vec::with_capacity(file.size() as usize); // @audit unbounded memory allocation file.read_to_end(&mut target)?; drop(file); make_symlink(&outpath, &target, &self.shared.files)?; continue; } ``` `src/read/mod.rs#L399-L405` (reviewed commit `6f09b306`); the same code is at `src/read.rs#L417-L418` in released v8.6.0. Both inputs are attacker-controlled: -…
Recommended action: Upgrade to 9.0.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
A critical architectural parser differential exists in the `zip` crate (` (&mut self, file: &mut ZipFile ) -> ZipResult { file.safe_prepare_path(&self.outpath, &mut outpath, None:: bool)>)?; let mut outfile = fs::File::create(&outpath)?; io::copy(file, &mut outfile)?; Ok(()) } ``` - `src/write.rs:L1552`: The crate explicitly exposes `shallow_copy_file`, an API that constructs dual-header desynchronizations by adding a new CDFH entry with an alias name pointing to an existing file without updating the original LFH. Threat Scenario & Severity Justification (10.0 / 9.9 Critical) 1. Security Control Evasion: An adversary crafts a ZIP archive where: - Central Directory Header declares: `doc_report.pdf` (Clean document) - Local File Header declares: `cron_worker.sh` (Malicious root backdoor) 2. The archive is uploaded through a web portal or API endpoint protected by security gateways (WAF, Anti-Virus, Content Disarm & Reconstruction). The security gateway inspects the…
Recommended action: Upgrade to 9.0.5 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
`ZipStreamReader::extract()` applies Unix permissions through extracted symlinks without validating the symlink target stays within the destination For further details see: https://github.com/zip-rs/zip2/security/advisories/GHSA-4684-h2q9-2vcp
Recommended action: Upgrade to 9.0.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
The `zip` crate preserves privileged Unix permission bits (SUID, SGID, and sticky bits) from ZIP `external_attributes` during extraction, instead of masking them to safe permission bits. If a privileged process (for example, `root` in an installer, CI/CD pipeline, or container build) extracts an attacker-controlled ZIP archive using `ZipArchive::extract()` or the stream extraction API, files can be created as setuid-root or setgid. This behavior allows the creation of SUID/SGID files during extraction, which can lead to local privilege escalation depending on the execution environment. For further details see: https://github.com/zip-rs/zip2/security/advisories/GHSA-vv5m-jxxh-4627
Recommended action: Upgrade to 9.0.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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
Recommended action: Upgrade to 9.0.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
In the archive extraction routine of affected versions of the zip crate, symbolic links earlier in the archive are allowed to be used for later files in the archive without validation of the final canonicalized path, allowing maliciously crafted archives to overwrite arbitrary files in the file system when extracted. Details This is a variant of the zip-slip vulnerability, we can make the extraction logic step outside of the target directory by creating a symlink to the parent directory and then extracting further files through that symlink. The documentation of the [::zip::read::ZipArchive::extract] method is in my opinion implying this should not happen: "Paths are sanitized with ZipFile::enclosedname." ... [::zip::read::FileOptions::enclosedname] ... is resistant to path-based exploits ... can’t resolve to a path outside the current directory. Most archive software either decline to extract symlinks that traverse out of the directory or defer creation of symlinks after all…
Recommended action: Upgrade to 2.3.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.