CVE-2026-53653: Unauthenticated Denial of Service via Unbounded Image Derivative Dimensions in Grav CMS

Grav CMS is an open-source flat-file Content Management System written in PHP. A central element of its architecture is the dynamic parsing, optimization, and routing of media assets directly from physical disk layouts. To support on-the-fly rendering and image modifications, Grav includes a routing fallback mechanism that intercepts requests for static assets and parses dynamic processing arguments from the query string.

This dynamic pipeline exposes a critical attack surface to unauthenticated remote individuals. By targeting local image assets, attackers can append query parameters containing malicious arguments to execute resource-intensive media rendering routines. This vulnerability falls under the classification of CWE-770 (Allocation of Resources Without Limits or Throttling).

The consequence of exploiting this vulnerability is a complete denial of service across the hosting platform. Because the dynamic operations are processed using memory-intensive native C-libraries, a series of requests can rapidly exhaust the host's physical RAM. The process bypasses standard runtime constraints configured in the application environment, causing entire server pools to crash.

The underlying flaw resides in the routing layer of Grav, specifically within the fallbackUrl($path) method in the system/src/Grav/Common/Grav.php file. When a direct path to a media asset is requested and the static file is missing or requires dynamic adjustments, the request is dispatched to this fallback router. The fallback router resolves the physical file, loads it into memory as a Medium object, and extracts the associated URI parameters to apply processing rules.

During this resolution phase, the code iterates through the parsed parameters of the URI query string. If a parameter key belongs to the static ImageMedium::$magic_actions list, the application dynamically executes the corresponding method using PHP's call_user_func_array function, passing the query parameter values directly as arguments to the graphics rendering engine.

The critical vulnerability is that the application dispatches these arguments directly to PHP's underlying image extensions (either GD or Imagick) without performing any boundary or ceiling validation. Graphic-processing drivers operate by allocating continuous pixel arrays on the system heap. The memory requirement for processing a dynamic image scale is proportional to the target dimensions:

$$\text{Memory Allocation} = \text{Width} \times \text{Height} \times 4 \text{ bytes}$$

Because these allocations occur within the native memory space of the underlying C dependencies (such as libgd or imagemagick), they bypass PHP's standard memory manager (emalloc) and do not respect the memory_limit directive configured in php.ini. Consequently, the operating system's Out-Of-Memory (OOM) killer is forced to terminate the entire PHP-FPM worker or web server process to reclaim memory, inducing a denial of service.

To understand the mechanics, we must examine the vulnerable execution loop in system/src/Grav/Common/Grav.php before the patch:

// Vulnerable Code Path
if (isset($media[$media_file])) {
    /** @var Medium $medium */
    $medium = $media[$media_file];
    foreach ($uri->query(null, true) as $action => $params) {
        // Unsanitized dispatch of user-supplied arguments to the image engine
        if (in_array($action, ImageMedium::$magic_actions, true)) {
            call_user_func_array([&$medium, $action], explode(',', (string) $params));
        }
    }
    Utils::download($medium->path(), false);
}

This loop splits user parameters by commas and passes them directly to methods like ImageMedium::resize(). There is no verification of the resulting image dimension area. The patched code introduces a dynamic limits check based on new configuration controls:

// Patched Code Path
if ($config->get('system.images.url_actions', false)) {
    $max_pixels = (int) $config->get('system.images.max_pixels', 25000000);
    foreach ($uri->query(null, true) as $action => $params) {
        if (in_array($action, ImageMedium::$magic_actions, true)) {
            $args = explode(',', (string) $params);
            
            // Reject dynamic transformations that exceed the total-pixel ceiling
            if ($max_pixels > 0 && isset(ImageMedium::$magic_resize_actions[$action])) {
                $positions = ImageMedium::$magic_resize_actions[$action];
                $w_pos = $positions[count($positions) - 2] ?? null;
                $h_pos = $positions[count($positions) - 1] ?? null;
                $width = ($w_pos !== null && isset($args[$w_pos]) && is_numeric($args[$w_pos])) ? (int) $args[$w_pos] : 0;
                $height = ($h_pos !== null && isset($args[$h_pos]) && is_numeric($args[$h_pos])) ? (int) $args[$h_pos] : 0;
                if ($width > 0 && $height > 0 && ($width * $height) > $max_pixels) {
                    return false;
                } 
            }
            call_user_func_array([&$medium, $action], $args);
        }
    }
}

The patch restricts dynamic operations by introducing the system.images.url_actions configuration, which defaults to false. It also enforces a limit of 25 megapixels via system.images.max_pixels. However, if the site administrator enables dynamic URL actions, the validation logic remains exposed to bypass attempts.

Exploitation of CVE-2026-53653 does not require authentication or complex configurations. An attacker merely needs to identify a valid image asset hosted within a vulnerable Grav instance. This can typically be discovered by inspecting the public pages of the site, which expose assets located in directory paths under /user/pages/ or /user/themes/.

Once an asset is located, the attacker issues an HTTP GET request appending the resize query parameter with high coordinates. The structure of the request is straightforward:

GET /user/pages/01.home/image.jpg?resize=50000,50000 HTTP/1.1
Host: target.local
User-Agent: Mozilla/5.0
Accept: */*

When this request is handled, the server's fallback router receives the request, parses the query string, and instantiates the image-resizing pipeline. The PHP extension attempts to allocate $50,000 \times 50,000 \times 4 \text{ bytes} \approx 10 \text{ GB}$ of RAM. Because this request fails to fit in physical RAM, the server terminates process execution immediately, leading to a denial of service.

If a system administrator enables system.images.url_actions = true to maintain support for legacy dynamic image processing, the current implementation of the patch is vulnerable to several logical bypasses.

The primary bypass involves a single-dimension auto-resizing flaw. The patch's boundary check requires both variables $width and $height to be strictly greater than zero to calculate the total pixels. If an attacker passes only one dimension, such as ?resize=50000, the array contains only one item. The variable $height is evaluated as 0. Because the condition $width > 0 && $height > 0 evaluates to false, the pixel validation check is bypassed. The dynamic handler then delegates to the image wrapper, which automatically scales the missing height to preserve the aspect ratio, allocating an enormous memory space and causing the system to crash.

Another bypass vector is the use of negative values. The check explicitly validates that $width > 0 and $height > 0. If an attacker inputs negative integers (e.g., ?resize=-20000,-20000), the comparison fails, bypassing the validation block. Depending on how the underlying C extension parses negative dimensions, these inputs are often interpreted as absolute values or cast into large unsigned integers, triggering the allocation fault.

Finally, the default threshold of 25 megapixels allows substantial resource consumption. A persistent attacker can make multiple concurrent requests using randomized dimensions just below the threshold (e.g., ?resize=4990,4990). Because each distinct query string avoids the cache, the server is forced to continuously re-render large images, leading to CPU and memory exhaustion under modest request volumes.

The primary and recommended action is to upgrade Grav CMS to version 1.7.53 or 2.0.0-rc.8. These releases introduce essential security bounds and configuration switches to handle dynamic URL queries securely.

To mitigate the flaw without upgrading immediately, administrators must explicitly disable dynamic image query actions. Ensure that the system/config/system.yaml contains the following setting:

images:
  url_actions: false

This setting disables the URL-processing path entirely while leaving normal page-rendering and theme transformations intact. If dynamic image operations are required, administrators can implement a virtual patch via a Web Application Firewall (WAF) or a reverse proxy. The following custom rule pattern can be used to detect and block suspicious dynamic resizing parameters on assets in access logs or web filters:

\.(jpg|jpeg|png|gif|webp)\?(resize|forceResize|cropZoom)=([\d\-,]+)