php-image-resize EUVD-2026-97495

Exploitation requires that the target application instantiate ImageResize (lib/ImageResize.php) on attacker-controllable image input - i.e. an upload or URL-fetch feature that passes untrusted images to GD imagecreatefrom* via the constructor - on a vulnerable version before 3.0.1 where no pixel limit exists. The limiting factors are: the attacker must have a path to submit images into the resize pipeline (any upload endpoint suffices, no authentication is indicated by PR:N); impact is availability-only, crashing the individual PHP worker rather than achieving code execution or data access; and deployments on 3.0.1+ with the default $max_source_pixels=15,000,000 guard, or any version where callers reject oversized images upstream, are not exploitable.

This is a genuine availability risk but not an emergency. All signals point to a single, consistent conclusion: the CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:N/UI:N) describes a network-reachable, low-complexity, unauthenticated attack, but impact is confined to availability only (VC:N/VI:N/VA:H) - there is no confidentiality or integrity loss, which is why the 8.7 'High' score does not rise to Critical. The attack is clearly automatable (a single tiny uploaded file reliably crashes a worker), which supports an elevated score. Weighing against urgency: there is no CISA KEV listing and no POC flagged in the input, so this is 'no public exploit identified at time of analysis' rather than active exploitation. EPSS and SSVC values were not supplied, so exploitation probability cannot be quantified from the data given. The real-world risk is also gated by exposure - only deployments that pass untrusted/uploaded images through the vulnerable ImageResize constructor are affected, and the crash terminates one PHP-FPM worker (transient DoS) rather than the whole host. Note a classification nuance: the input labels this CWE-409 (data amplification), while the vendor's own patch notes call it CWE-400 (uncontrolled resource consumption); both are defensible for a decompression/image bomb and this does not change the risk picture. Net: prioritize patching for any internet-facing app that resizes user-supplied images, but treat it as a stability/DoS fix, not a breach risk.

An attacker locates a web application that uses php-image-resize (< 3.0.1) to process user-uploaded images and submits a small, highly compressed image (e.g. a ~56 KB PNG whose canvas is 4000×4000 pixels). When the ImageResize constructor calls imagecreatefrompng() the file decompresses to ~61 MB of raw bitmap, exceeding PHP's memory_limit and fatally terminating the PHP-FPM worker; repeating this exhausts the worker pool and denies service. No public exploit is identified at time of analysis, but the technique is trivial to reproduce.