{"id":"CVE-2026-61449","aliases":["EUVD-2026-44647","GHSA-8h9x-89f2-m7x3","GHSA-v626-428r-43p8"],"status":"published","title":"Grav before 2.0.2 Decompression Bomb via Forged ZIP Size","description":"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's ZIP central-directory header (ZipArchive::statIndex()['size']) 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.","severity":{"version":"4.0","score":7.1,"vector":"CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:P/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N","level":"high","assessor":"cna","from":"cve"},"epss":{"day":"2026-11-10","score":0.00299,"percentile":0.2273,"model":"v2026.06.15"},"facts":{"in_kev":false,"known_exploited":false,"public_exploit":false,"fix_available":true},"cwes":["CWE-409"],"published":"2026-07-15T11:25:43Z","modified":"2026-10-28T02:30:22Z","fixes":[{"ecosystem":"Packagist","package":"getgrav/grav","fixed_in":["2.0.2"],"sources":["ghsa","osv"]}],"affected":[{"source":"ghsa","ecosystem":"Packagist","package":"getgrav/grav","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"2.0.1"},{"last_affected":"2.0.1"},{"fixed":"2.0.2"}]}],"versions":["2.0.1"]},{"source":"osv","ecosystem":"Packagist","package":"getgrav/grav","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"2.0.1"},{"fixed":"2.0.2"}]}],"versions":["2.0.1"]}],"products":[{"vendor":"getgrav","product":"grav"}],"references":[{"url":"https://github.com/getgrav/grav/security/advisories/GHSA-8h9x-89f2-m7x3","tags":["vendor-advisory","exploit","advisory","web"]},{"url":"https://www.vulncheck.com/advisories/grav-before-decompression-bomb-via-forged-zip-size","tags":["third-party-advisory","advisory","web"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2026-61449","tags":["advisory"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2026-61841","tags":["advisory"]},{"url":"https://github.com/advisories/GHSA-8h9x-89f2-m7x3"},{"url":"https://github.com/advisories/GHSA-v626-428r-43p8"},{"url":"https://github.com/CVEProject/cvelistV5/tree/main/cves/2026/61xxx/CVE-2026-61449.json","tags":["advisory"]},{"url":"https://github.com/getgrav/grav","tags":["package"]}],"sources":{"cve":[{"id":"CVE-2026-61449","title":"Grav before 2.0.2 Decompression Bomb via Forged ZIP Size","description":"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's ZIP central-directory header (ZipArchive::statIndex()['size']) 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.","status":"published","published":"2026-07-15T11:25:43.802Z","modified":"2026-10-08T15:23:32.555Z","cvss":[{"version":"4.0","score":7.1,"vector":"CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:P/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N","level":"high","assessor":"cna"},{"version":"3.1","score":6.5,"vector":"CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:N/A:H","level":"medium","assessor":"cna"}],"cwes":["CWE-409"],"updated_at":"2026-11-02T14:19:53.4444Z"}],"euvd":[{"id":"EUVD-2026-44647","description":"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's ZIP central-directory header (ZipArchive::statIndex()['size']) 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.","status":"published","published":"2026-07-15T11:25:43Z","modified":"2026-10-08T15:23:32Z","cvss":[{"version":"4.0","score":7.1,"vector":"CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:P/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N","level":"high"}],"updated_at":"2026-11-02T17:27:31.696571Z"}],"ghsa":[{"id":"GHSA-8h9x-89f2-m7x3","title":"Grav: Decompression-bomb size cap bypassed by forged ZIP size in ZipArchiver/Installer","description":"### Summary\n\nThe 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.\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['size'];          // declared central-directory size\nif ($maxSize \u003e 0 \u0026\u0026 $totalSize \u003e $maxSize) { ... reject ... }\n```\n\n`$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.\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'\\x00' * (10*1024*1024)\nwith zipfile.ZipFile('bomb.zip','w',zipfile.ZIP_DEFLATED) as z:\n    z.writestr('big.bin', data)\nraw = bytearray(open('bomb.zip','rb').read())\nraw = raw.replace(struct.pack('\u003cI', 10*1024*1024), struct.pack('\u003cI', 1))\nopen('bomb_forged.zip','wb').write(raw)\n```\n\nDrive the exact pre-extraction loop, then extract:\n\n```php\n$zip = new ZipArchive(); $zip-\u003eopen('bomb_forged.zip');\n$total = 0;\nfor ($i = 0; $i \u003c $zip-\u003ecount(); $i++) { $total += (int) $zip-\u003estatIndex($i)['size']; }\n// =\u003e $total === 1   (what the 1 GiB bound checks: PASSES)\n$zip-\u003eextractTo('/tmp/zout');\n// =\u003e filesize('/tmp/zout/big.bin') === 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'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.","status":"published","published":"2026-09-17T14:53:33Z","modified":"2026-09-17T14:53:35Z","cvss":[{"version":"3.1","score":6.5,"vector":"CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:N/A:H","level":"medium"}],"updated_at":"2026-11-02T14:41:17.136201Z"},{"id":"GHSA-v626-428r-43p8","title":"Duplicate Advisory: Grav: Decompression-bomb size cap bypassed by forged ZIP size in ZipArchiver/Installer","description":"### Duplicate Advisory\nThis advisory has been withdrawn because it is a duplicate of GHSA-8h9x-89f2-m7x3. This link is maintained to preserve external references.\n\n### Original Description\nGrav 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's ZIP central-directory header (ZipArchive::statIndex()['size']) 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.","status":"withdrawn","published":"2026-07-15T12:32:04Z","modified":"2026-09-17T14:53:19Z","cvss":[{"version":"4.0","score":7.1,"vector":"CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:P/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N","level":"high"},{"version":"3.1","score":6.5,"vector":"CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:N/A:H","level":"medium"}],"cwes":["CWE-409"],"updated_at":"2026-11-02T14:41:17.136201Z"}],"nvd":[{"id":"CVE-2026-61449","description":"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's ZIP central-directory header (ZipArchive::statIndex()['size']) 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.","status":"published","published":"2026-07-15T12:18:19.747Z","modified":"2026-10-24T21:10:00.13Z","cvss":[{"version":"4.0","score":7.1,"vector":"CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:P/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X","level":"high","assessor":"secondary"},{"version":"3.1","score":6.5,"vector":"CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:N/A:H","level":"medium","assessor":"secondary"}],"cwes":["CWE-409"],"updated_at":"2026-11-02T14:12:29.879716Z"}],"osv":[{"id":"CVE-2026-61449","title":"Grav before 2.0.2 Decompression Bomb via Forged ZIP Size","description":"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's ZIP central-directory header (ZipArchive::statIndex()['size']) 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.","status":"published","published":"2026-07-15T11:25:43.802Z","modified":"2026-10-28T02:30:22.022885511Z","cvss":[{"version":"4.0","score":7.1,"vector":"CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:P/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N","level":"high"}],"cwes":["CWE-409"],"updated_at":"2026-11-02T15:45:12.933503Z"},{"id":"GHSA-8h9x-89f2-m7x3","title":"Grav: Decompression-bomb size cap bypassed by forged ZIP size in ZipArchiver/Installer","description":"### Summary\n\nThe 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.\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['size'];          // declared central-directory size\nif ($maxSize \u003e 0 \u0026\u0026 $totalSize \u003e $maxSize) { ... reject ... }\n```\n\n`$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.\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'\\x00' * (10*1024*1024)\nwith zipfile.ZipFile('bomb.zip','w',zipfile.ZIP_DEFLATED) as z:\n    z.writestr('big.bin', data)\nraw = bytearray(open('bomb.zip','rb').read())\nraw = raw.replace(struct.pack('\u003cI', 10*1024*1024), struct.pack('\u003cI', 1))\nopen('bomb_forged.zip','wb').write(raw)\n```\n\nDrive the exact pre-extraction loop, then extract:\n\n```php\n$zip = new ZipArchive(); $zip-\u003eopen('bomb_forged.zip');\n$total = 0;\nfor ($i = 0; $i \u003c $zip-\u003ecount(); $i++) { $total += (int) $zip-\u003estatIndex($i)['size']; }\n// =\u003e $total === 1   (what the 1 GiB bound checks: PASSES)\n$zip-\u003eextractTo('/tmp/zout');\n// =\u003e filesize('/tmp/zout/big.bin') === 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'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.","status":"published","published":"2026-09-17T14:53:33Z","modified":"2026-09-17T15:00:05.915123836Z","cvss":[{"version":"3.1","score":6.5,"vector":"CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:N/A:H","level":"medium"}],"updated_at":"2026-11-02T15:46:42.437513Z"},{"id":"GHSA-v626-428r-43p8","title":"Duplicate Advisory: Grav: Decompression-bomb size cap bypassed by forged ZIP size in ZipArchiver/Installer","description":"### Duplicate Advisory\nThis advisory has been withdrawn because it is a duplicate of GHSA-8h9x-89f2-m7x3. This link is maintained to preserve external references.\n\n### Original Description\nGrav 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's ZIP central-directory header (ZipArchive::statIndex()['size']) 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.","status":"withdrawn","published":"2026-07-15T12:32:04Z","modified":"2026-09-17T15:00:05.906568665Z","cvss":[{"version":"3.1","score":6.5,"vector":"CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:N/A:H","level":"medium"},{"version":"4.0","score":7.1,"vector":"CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:P/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N","level":"high"}],"cwes":["CWE-409"],"updated_at":"2026-11-02T15:46:56.639206Z"}]}}