CVE-2026-109398 in php-image-resize
Summary
by MITRE • 10/12/2026
Gumlet php-image-resize before 3.0.1 contains a denial of service vulnerability because the ImageResize constructor in lib/ImageResize.php passes images to GD imagecreatefrom* functions without pixel limits. Remote attackers can upload small, highly compressed images that decode to large bitmaps, exhausting PHP memory and terminating the worker process.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 10/12/2026
The vulnerability identified in Gumlet php-image-resize prior to version 3.0.1 represents a critical resource exhaustion flaw rooted in improper input validation during image processing operations. This library is widely utilized for server-side manipulation of raster images, yet it fails to enforce strict boundaries on the dimensions or memory footprint of decoded bitmaps before rendering them into PHP's GD extension functions. Specifically, the ImageResize constructor within lib/ImageResize.php delegates raw image data directly to gd_imagecreatefrom* family functions without implementing any pre-processing checks for pixel limits or maximum resolution constraints. This architectural oversight allows attackers to exploit the inherent behavior of certain image formats where a file with minimal storage size can expand into an excessively large bitmap upon decoding, thereby triggering a denial of service condition that disrupts normal application functionality and consumes server resources disproportionately.
From a technical perspective, this flaw aligns closely with CWE-400, which describes uncontrolled resource consumption vulnerabilities. The core issue lies in the lack of sanitization regarding image dimensions before they are passed to the underlying graphics library. When an attacker uploads a specially crafted image file that is highly compressed but contains metadata or data structures indicating massive width and height values, the GD extension attempts to allocate memory for a bitmap corresponding to those declared dimensions rather than the actual visual content size. Since PHP operates within defined memory limits set by php.ini configurations such as memory_limit, attempting to instantiate an impossibly large image buffer causes the script execution to abort abruptly due to out-of-memory errors. This behavior effectively terminates the worker process handling the request, leading to service unavailability for subsequent requests if not properly handled by a supervisor or restart mechanism, thus creating a reliable vector for denial of service attacks against any application relying on this library for image uploads and resizing tasks.
The operational impact of this vulnerability is significant for web applications that accept user-generated content involving images without rigorous server-side validation prior to processing. An attacker can exploit this weakness by uploading small, maliciously crafted files designed specifically to trigger the memory exhaustion condition upon decoding. Because the attack payload remains compact during transmission and storage until the moment of processing, it bypasses many traditional size-based upload filters that only check file bytes rather than decoded pixel dimensions. This results in a high-availability risk where repeated exploitation can lead to sustained service degradation or complete outage depending on how the application manages failed processes and resource allocation limits. In environments running multiple concurrent requests through PHP-FPM or similar workers, exhausting memory for one request may impact overall system stability if global resources are shared without adequate isolation mechanisms.
To mitigate this vulnerability, developers must upgrade immediately to version 3.0.1 or later of the Gumlet php-image-resize library where these checks have been implemented. For applications unable to update instantly due to dependency constraints, implementing a pre-processing validation step is essential. This involves decoding image metadata using safe functions such as getimagesize before passing data to GD libraries to verify that width and height values fall within acceptable thresholds defined by business logic or security policies. Additionally, enforcing strict memory limits at the PHP configuration level can help contain the blast radius of any successful exploitation attempt. It is also recommended to integrate web application firewall rules that detect anomalous image upload patterns and to employ sandboxed environments for processing untrusted media files so that resource exhaustion does not compromise the host system or other tenant processes in multi-tenant architectures.
This vulnerability maps directly to MITRE ATT&CK technique T1496, Resource Hijacking, specifically under sub-technique T1496.002 which involves Denial of Service through resource consumption. By exploiting this flaw, adversaries can achieve service disruption without needing elevated privileges or complex exploitation chains beyond a simple file upload interface. The simplicity of the attack vector makes it particularly dangerous in public-facing applications where image uploads are common features such as social media platforms, e-commerce sites allowing product photo submissions, and content management systems. Security teams should prioritize patching this library across all environments and conduct audits to ensure that no custom implementations bypass the built-in protections introduced in newer versions of the software. Continuous monitoring for unusual spikes in memory usage associated with image processing endpoints can also serve as an effective detection mechanism for ongoing exploitation attempts while remediation efforts are underway.