https://cve.radiocsirt.org Contains only the most 10 recent entries. http://www.rssboard.org/rss-specification python-feedgen en Tue, 06 Oct 2026 07:12:22 +0000 https://cve.radiocsirt.org/vuln/euvd-2026-338098 EUVD-2026-338098 https://cve.radiocsirt.org/vuln/euvd-2026-338098 https://cve.radiocsirt.org/vuln/fkie_cve-2026-61449 <p>Grav 2.0.1 contains a decompression-bomb size-cap bypass in ZipArchiver and GPM\Installer. The size bound introduced in 2.0.1 sums the uncompressed size declared in each entry&#39;s ZIP central-directory header (ZipArchive::statIndex()[&#39;size&#39;]) and rejects archives exceeding system.gpm.archive.max_uncompressed_size before extraction. Because this declared size is attacker-forgeable and is not cross-checked against the actual inflated stream, a crafted archive declaring tiny per-entry sizes passes the cap while extractTo() writes the real, much larger content, filling disk or exhausting inodes. The archive must be supplied by a package source or admin upload (admin/operator trust). Fixed in 2.0.2. This is an incomplete fix for GHSA-928x-9mpw-8h56.</p> <p>Grav 2.0.1 contains a decompression-bomb size-cap bypass in ZipArchiver and GPM\Installer. The size bound introduced in 2.0.1 sums the uncompressed size declared in each entry&#39;s ZIP central-directory header (ZipArchive::statIndex()[&#39;size&#39;]) and rejects archives exceeding system.gpm.archive.max_uncompressed_size before extraction. Because this declared size is attacker-forgeable and is not cross-checked against the actual inflated stream, a crafted archive declaring tiny per-entry sizes passes the cap while extractTo() writes the real, much larger content, filling disk or exhausting inodes. The archive must be supplied by a package source or admin upload (admin/operator trust). Fixed in 2.0.2. This is an incomplete fix for GHSA-928x-9mpw-8h56.</p> https://cve.radiocsirt.org/vuln/fkie_cve-2026-61449 https://cve.radiocsirt.org/vuln/ghsa-8h9x-89f2-m7x3 <p><strong>Affected:</strong> Packagist: getgrav/grav</p> <p>### Summary</p> <p>The decompression-bomb bound added in 2.0.1 (commit 1c1003c) sums `ZipArchive::statIndex($i)[&#39;size&#39;]` and rejects an archive whose declared uncompressed total exceeds `system.gpm.archive.max_uncompressed_size` (default 1 GiB) before extracting (`ZipArchiver.php:77-86`; same logic in `GPM\Installer::unZip` at `Installer.php:228-238`). `statIndex()[&#39;size&#39;]` is the uncompressed size declared in the ZIP central directory, which is attacker-forgeable and is not checked against the actual inflated stream. An archive declaring 1 byte per entry passes the cap while `extractTo()` writes the real (large) content. The entry-count and nesting-depth caps count real structure and still hold; only the size dimension is defeated, so the disk-fill / inode-exhaustion case the bound targets is not prevented. Incomplete fix for GHSA-928x-9mpw-8h56.</p> <p>### Details</p> <p>`extract()`/`unZip()` validate every entry up front, then call `Folder::create` + `extractTo`. The size check is:</p> <p>```php $totalSize += (int) $stat[&#39;size&#39;]; // declared central-directory size if ($maxSize &gt; 0 &amp;&amp; $totalSize &gt; $maxSize) { ... reject ... } ```</p> <p>`$stat[&#39;size&#39;]` is read from the central directory, which the archive author writes. libzip does not cross-check declared-vs-actual size during `extractTo`, so a forged-small value passes the gate and the real stream inflates to disk. The `max_files` (entry count) and `max_depth` (entry-name segments) checks are not forgeable this way.</p> <p>### PoC</p> <p>Build a 10 KiB…</p> <p><strong>Affected:</strong> Packagist: getgrav/grav</p> <p>### Summary</p> <p>The decompression-bomb bound added in 2.0.1 (commit 1c1003c) sums `ZipArchive::statIndex($i)[&#39;size&#39;]` and rejects an archive whose declared uncompressed total exceeds `system.gpm.archive.max_uncompressed_size` (default 1 GiB) before extracting (`ZipArchiver.php:77-86`; same logic in `GPM\Installer::unZip` at `Installer.php:228-238`). `statIndex()[&#39;size&#39;]` is the uncompressed size declared in the ZIP central directory, which is attacker-forgeable and is not checked against the actual inflated stream. An archive declaring 1 byte per entry passes the cap while `extractTo()` writes the real (large) content. The entry-count and nesting-depth caps count real structure and still hold; only the size dimension is defeated, so the disk-fill / inode-exhaustion case the bound targets is not prevented. Incomplete fix for GHSA-928x-9mpw-8h56.</p> <p>### Details</p> <p>`extract()`/`unZip()` validate every entry up front, then call `Folder::create` + `extractTo`. The size check is:</p> <p>```php $totalSize += (int) $stat[&#39;size&#39;]; // declared central-directory size if ($maxSize &gt; 0 &amp;&amp; $totalSize &gt; $maxSize) { ... reject ... } ```</p> <p>`$stat[&#39;size&#39;]` is read from the central directory, which the archive author writes. libzip does not cross-check declared-vs-actual size during `extractTo`, so a forged-small value passes the gate and the real stream inflates to disk. The `max_files` (entry count) and `max_depth` (entry-name segments) checks are not forgeable this way.</p> <p>### PoC</p> <p>Build a 10 KiB…</p> https://cve.radiocsirt.org/vuln/ghsa-8h9x-89f2-m7x3