Grav before 2.0.2 Decompression Bomb via Forged ZIP Size
Default status is the baseline for the product, each version can override it (e.g. patched versions marked unaffected).
| Vendor | Product | Default status | Versions | |||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| getgrav | grav | unaffected |
|
No data.
No data.
| Vendor | Product | Versions | ||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Getgrav | Grav |
|
| Source | ID | Title |
|---|---|---|
Github GHSA |
GHSA-8h9x-89f2-m7x3 | Grav: Decompression-bomb size cap bypassed by forged ZIP size in ZipArchiver/Installer |
No CVSS v3.0
No CVSS v2
This CVE is not in the KEV list.
Exploit prediction score: < 1% (0.299% probability within 30 days)
| Type | Values Removed | Values Added |
|---|---|---|
| Metrics |
ssvc
|
| Type | Values Removed | Values Added |
|---|---|---|
| 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. | |
| Title | Grav before 2.0.2 Decompression Bomb via Forged ZIP Size | |
| First Time appeared |
Getgrav
Getgrav grav |
|
| Weaknesses | CWE-409 | |
| CPEs | cpe:2.3:a:getgrav:grav:*:*:*:*:*:*:*:* | |
| Vendors & Products |
Getgrav
Getgrav grav |
|
| References |
| |
| Metrics |
cvssV3_1
|