Which versions of Grav CMS are affected by CVE-2026-61449?

Grav CMS 2.0.1 contains a denial-of-service vulnerability in package decompression that allows administrators or trusted package sources to exhaust disk storage and inodes, risking service…. A patch is available.

How to fix or mitigate CVE-2026-61449?

Within 24 hours, identify all systems running Grav CMS 2.0.1 and initiate upgrade to version 2.0.2. If immediate upgrade is not possible, restrict package upload privileges to essential administrators and monitor disk usage. Within 7 days, complete the upgrade of all Grav CMS instances to version 2.0.2. Within 30 days, verify patch deployment across infrastructure and implement formal controls limiting package upload permissions.

Grav CMS CVE-2026-61449

Q: What is the CVSS score of CVE-2026-61449?

CVE-2026-61449 has a CVSS 4.0 base score of 7.1 (High). CVSS 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. EPSS exploitation probability: 0.2%.

EUVD-2026-44647 HIGH

Improper Handling of Highly Compressed Data (Data Amplification) (CWE-409)

2026-07-15 VulnCheck

GHSA-v626-428r-43p8

Authentication Bypass Grav Getgrav

7.1

CVSS 4.0 · Vendor: VulnCheck

Severity by source

Vendor (VulnCheck) PRIMARY

7.1 HIGH

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

vuln.today AI

4.5 MEDIUM

Requires admin/operator upload or a trusted package source (PR:H) and an operator action to trigger extraction (UI:R); impact is availability-only disk/inode exhaustion (A:H).

3.1 AV:N/AC:L/PR:H/UI:R/S:U/C:N/I:N/A:H

4.0 AV:N/AC:L/AT:N/PR:H/UI:P/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N

Primary rating from Vendor (VulnCheck).

CVSS VectorVendor: VulnCheck

Attack Vector

Network

Attack Complexity

Low

Privileges Required

None

User Interaction

Scope

Lifecycle Timeline

Patch available

Jul 15, 2026 - 13:03 EUVD

Analysis Generated

Jul 15, 2026 - 12:22 vuln.today

CVE Published

Jul 15, 2026 - 11:25 cve.org

HIGH 7.1

DescriptionCVE.org

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.

AnalysisAI

Denial of service in Grav CMS 2.0.1 lets a trusted package source or admin-level uploader bypass the newly added decompression-bomb size cap and exhaust disk space or inodes on the host. The 2.0.1 cap trusts the attacker-forgeable uncompressed size declared in each ZIP central-directory entry rather than the actual inflated stream, so a crafted archive declaring tiny sizes slips past the check while extraction writes the real, far larger payload. This is an incomplete fix for GHSA-928x-9mpw-8h56, corrected in 2.0.2; no public exploit identified at time of analysis and it is not listed in CISA KEV.

Technical ContextAI

Grav is a PHP-based flat-file CMS, and the flaw lives in its archive-handling code - the ZipArchiver helper and the GPM\Installer used for plugin/theme/package installation. The 2.0.1 mitigation summed ZipArchive::statIndex()['size'] across entries and rejected archives whose declared total exceeded system.gpm.archive.max_uncompressed_size before calling extractTo(). The root cause is CWE-409 (Improper Handling of Highly Compressed Data / data amplification): the size bound is derived from the ZIP central-directory metadata, which is fully attacker-controlled and never reconciled against the number of bytes actually inflated by extractTo(). Because PHP's ZipArchive reports the header-declared size rather than the true decompressed length, the pre-extraction guard can be trivially defeated by writing false per-entry sizes.

RemediationAI

Upgrade to Grav 2.0.2, which cross-checks the actual inflated stream size against the cap instead of trusting the declared central-directory sizes (Vendor-released patch: 2.0.2; see GHSA-8h9x-89f2-m7x3). Until you can patch, restrict who can supply archives: limit admin panel plugin/theme upload permissions to a minimal set of trusted operators, and pin GPM package sources to trusted repositories only rather than arbitrary URLs - the trade-off is reduced convenience for installing third-party or ad-hoc packages. As a host-level compensating control, place Grav's extraction/temp and data directories on a filesystem with disk quotas or a dedicated partition so a bomb cannot exhaust the root volume or global inode table, accepting that legitimate large installs may hit the quota. Monitor free disk space and inode consumption during GPM operations to detect abuse. Reference: vendor advisory GHSA-8h9x-89f2-m7x3 and VulnCheck advisory linked above.