GHSA-4x9g-vw65-vvf9: Composer/getgrav/grav vulnerability
Summary An unauthenticated visitor exhausts server memory and CPU by requesting an image with oversized resize dimensions. One request drives a worker to several gigabytes of RAM and tens of seconds of CPU. A few concurrent requests take the host down.
Details Grav::fallbackUrl() (system/src/Grav/Common/Grav.php:800-804) loops over every query parameter and, when the name matches ImageMedium::$magicactions, calls that method on the medium with the comma-split value as arguments:
php foreach ($uri->query(null, true) as $action => $params) { if (inarray($action, ImageMedium::$magicactions, true)) { calluserfuncarray([&$medium, $action], explode(',', $params)); } }
forceResize runs with force=true, so it sets the output size to the attacker's values with no clamp against the source or any ceiling. The getgrav/image GD adapter then calls imagecreatetruecolor($w, $h). libgd allocates that buffer outside PHP's emalloc, so memorylimit does not cap it. Grav exposes no system.images.maxwidth/maxheight setting.
PoC Any page that serves an image works. With a 200x150 source image:
GET /home/test.png?forceResize=20000,20000
Measured on PHP 8.4.21 with memorylimit=128M:
- peak worker RSS 3,109 MB - 21.9 s CPU - HTTP 200, 1.6 MB response
8000x8000 already needs ~244 MB. The cache key includes the dimensions, so varying them forces fresh work on every request.
Impact Unauthenticated denial of service against any Grav site that serves images. No account, plugin, or non-default config required.
Fix Clamp the request-derived dimensions before dispatch, behind a configurable cap. The image library is the wrong layer; bound the arguments at the request boundary.
diff --- a/system/src/Grav/Common/Grav.php +++ b/system/src/Grav/Common/Grav.php @@ public function fallbackUrl($path) foreach ($uri->query(null, true) as $action => $params) { if (inarray($action, ImageMedium::$magicactions, true)) { - calluserfuncarray([&$medium, $action], explode(',', $params)); + $args = explode(',', $params); + $max = (int) $config->get('system.images.maxdimension', 8000); + if ($max > 0 + && inarray($action, ['resize', 'forceResize', 'cropResize', 'cropZoom', 'zoomCrop', 'crop'], true)) { + foreach ($args as $a) { + if (isnumeric($a) && (int) $a > $max) { + return false; // reject oversized derivative request + } + } + } + calluserfuncarray([&$medium, $action], $args); } }
Document system.images.maxdimension (default 8000) so operators can tune it. A total-pixel ceiling (width height) is a stricter alternative.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
composer/getgrav/gravto a version that resolves this vulnerability.Fixed in 1.7.53 - Upgrade
Upgrade
composer/getgrav/gravto a version that resolves this vulnerability.Fixed in 2.0.0-rc.8 - Configuration
Clamp request-derived image resize/crop dimensions in Grav's request boundary using the configurable cap `system.images.max_dimension` (default 8000) before dispatching actions like `forceResize`, `resize`, `cropResize`, `cropZoom`, `zoomCrop`, and `crop` (in `system/src/Grav/Common/Grav.php` fallbackUrl).
Grav (system images resize request handling) system.images.max_dimension = 8000
Event History
Frequently Asked Questions
What is the severity of GHSA-4x9g-vw65-vvf9?
The severity of GHSA-4x9g-vw65-vvf9 is rated as 74, indicating a significant risk due to memory and CPU exhaustion.
How do I fix GHSA-4x9g-vw65-vvf9?
To fix GHSA-4x9g-vw65-vvf9, update to the latest version of the Grav software that addresses the vulnerability.
What is the impact of GHSA-4x9g-vw65-vvf9?
GHSA-4x9g-vw65-vvf9 allows unauthenticated visitors to exhaust server resources, potentially taking down the host with several concurrent requests.
Who is affected by GHSA-4x9g-vw65-vvf9?
All users of the composer/getgrav/grav software version prior to the fix for GHSA-4x9g-vw65-vvf9 are affected.
When was GHSA-4x9g-vw65-vvf9 published?
GHSA-4x9g-vw65-vvf9 was published on August 14, 2026.