https://cve.radiocsirt.org Contains only the most 10 recent entries. http://www.rssboard.org/rss-specification python-feedgen en Tue, 06 Oct 2026 21:12:46 +0000 https://cve.radiocsirt.org/vuln/cve-2025-29787 <p><strong>Affected:</strong> zip-rs zip2</p> <p>`zip` is a zip library for rust which supports reading and writing of simple ZIP files. In the archive extraction routine of affected versions of the `zip` crate starting with version 1.3.0 and prior to version 2.3.0, 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. Users who extract untrusted archive files using the following high-level API method may be affected and critical files on the system may be overwritten with arbitrary file permissions, which can potentially lead to code execution. Version 2.3.0 fixes the issue.</p> <p><strong>Affected:</strong> zip-rs zip2</p> <p>`zip` is a zip library for rust which supports reading and writing of simple ZIP files. In the archive extraction routine of affected versions of the `zip` crate starting with version 1.3.0 and prior to version 2.3.0, 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. Users who extract untrusted archive files using the following high-level API method may be affected and critical files on the system may be overwritten with arbitrary file permissions, which can potentially lead to code execution. Version 2.3.0 fixes the issue.</p> https://cve.radiocsirt.org/vuln/cve-2025-29787 https://cve.radiocsirt.org/vuln/ghsa-94vh-gphv-8pm8 <p><strong>Affected:</strong> crates.io: zip</p> <p>### Summary</p> <p>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.</p> <p>### Details</p> <p>This is a variant of the [zip-slip](https://github.com/snyk/zip-slip-vulnerability) 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.</p> <p>The documentation of the [`::zip::read::ZipArchive::extract`] method is in my opinion implying this should not happen:</p> <p>&gt; &#34;Paths are sanitized with ZipFile::enclosed_name.&#34; ... &gt; [`::zip::read::FileOptions::enclosed_name`] ... is resistant to path-based exploits ... can’t resolve to a path outside the current directory.</p> <p>Most archive software either decline to extract symlinks that traverse out of the directory or defer creation of symlinks after all files have been created to prevent unexpected behavior when later entries depend on earlier symbolic link entries.</p> <p>### PoC</p> <p>https://gist.github.com/eternal-flame-AD/bf71ef4f6828e741eb12ce7fd47b7b85</p> <p>### Impact</p> <p>Users who extract untrusted archive files using the following high-level API method may be affected and critical files on the system may be overwritten with arbitrary file permissions, which can potentially lea…</p> <p><strong>Affected:</strong> crates.io: zip</p> <p>### Summary</p> <p>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.</p> <p>### Details</p> <p>This is a variant of the [zip-slip](https://github.com/snyk/zip-slip-vulnerability) 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.</p> <p>The documentation of the [`::zip::read::ZipArchive::extract`] method is in my opinion implying this should not happen:</p> <p>&gt; &#34;Paths are sanitized with ZipFile::enclosed_name.&#34; ... &gt; [`::zip::read::FileOptions::enclosed_name`] ... is resistant to path-based exploits ... can’t resolve to a path outside the current directory.</p> <p>Most archive software either decline to extract symlinks that traverse out of the directory or defer creation of symlinks after all files have been created to prevent unexpected behavior when later entries depend on earlier symbolic link entries.</p> <p>### PoC</p> <p>https://gist.github.com/eternal-flame-AD/bf71ef4f6828e741eb12ce7fd47b7b85</p> <p>### Impact</p> <p>Users who extract untrusted archive files using the following high-level API method may be affected and critical files on the system may be overwritten with arbitrary file permissions, which can potentially lea…</p> https://cve.radiocsirt.org/vuln/ghsa-94vh-gphv-8pm8