A critical vulnerability in imgproxy, the open-source image processing service, could let a remote attacker crash the service — and possibly run code — by submitting a specially crafted ICO image. Tracked as CVE-2026-123614, the flaw was published in the CVE record on 8 November 2026. It affects imgproxy versions 4.0.0 through 4.0.15 and is fixed in version 4.0.16.

The bug is an integer overflow in imgproxy's custom ICO loader, in the file vips/icoload.c. When the loader reads an ICO file, it takes the declared data size of an embedded image and adds 14 bytes for a synthetic BMP header before allocating memory. The problem is that the addition is done in 32-bit arithmetic. A declared size close to the 32-bit maximum can wrap around, so the allocator receives a tiny number instead of the real one. In the researcher's example, a declared size of 4,294,967,285 plus 14 produced an allocation of just three bytes — while the loader still tried to copy the full image data into a buffer starting 14 bytes in, 11 bytes beyond the end of the allocation.

The flaw was discovered independently in September 2026 by security researcher Mateo Fumis, who reported it privately to the project on 18 September. He confirmed the impact against the official v4.0.15 release: a valid ICO image returned a normal response, while the malformed image closed the connection and terminated the process, with logs showing heap corruption and an abort signal. An instrumented build confirmed the mechanism — a heap-buffer-overflow write 11 bytes beyond a three-byte region. He also validated the bug on an internet-accessible deployment under his control, where the malformed image produced a server error followed by a process crash and restart.

The upstream advisory, GHSA-hff9-5pqw-6w9f, rates the vulnerability Critical, with a CVSS score of 9.8, and lists possible remote code execution as an impact. The researcher's own validation demonstrated heap corruption and remotely triggerable denial of service; he did not demonstrate code execution, data access, or an integrity compromise. The CVE record classifies the weakness as CWE-122, a heap-based buffer overflow, and the advisory also cites CWE-190 for the integer overflow and CWE-787 for the out-of-bounds write. The flaw is not known to have been exploited in the wild.

What an attacker needs is the ability to get imgproxy to process an image they control. Depending on the application, that could be an unsigned processing endpoint, an upload workflow, or a source-URL feature that causes the application to request a transformation. Because imgproxy is often deployed as a shared service that resizes images on demand for websites and applications, a crash in its image-processing process disrupts image delivery for the operator and for other users sharing the service. A deployment without automatic recovery could stay unavailable until an operator restarts it, and repeated processing of the same crafted image could cause repeated crashes.

The fix, included in imgproxy 4.0.16, caps the declared size of an ICO entry at 10 megabytes before the allocation calculation, so the near-maximum value can never reach the wrapping addition. The patch also adds handling for allocation failures and cleanup on read failure, plus regression coverage for malformed ICO input. The researcher retested the original malformed image against the official v4.0.16 image and confirmed the fix: the image was rejected with an error stating the ICO image data was too large, ten consecutive attempts produced controlled errors with no restarts, and health checks returned normally.

Operators running imgproxy should upgrade to version 4.0.16 or later. The fix was released on 28 September, and the upstream advisory was published on 6 October, but the CVE record itself only appeared on 8 November — which is why the flaw is only now entering many vulnerability feeds. Anyone still running 4.0.15 or earlier should treat the upgrade as a priority, and should check whether their deployment allows untrusted images to reach the processing pipeline in the first place.