On this page (7 sections)

imgproxy, an image resizing server, has a critical flaw in the code that loads ICO (icon) files. According to the GitHub advisory GHSA-hff9-5pqw-6w9f, a specially crafted image can terminate the imgproxy process handling it and may lead to remote code execution through heap corruption. The fix is in version 4.0.16.

If you run imgproxy yourself, directly or inside a container, check your version now. The advisory's CVSS vector describes the attack as network-based, with no privileges and no user interaction required.

What happened

The advisory was published on the imgproxy repository on October 6, 2026, and was added to the GitHub Advisory Database, reviewed and last updated on October 30, 2026. It lists DarthSim as the publisher, mateofumis and JasonPuglisi as reporters, and JacobBrackett as analyst. The patch commit and the v4.0.16 release are linked from the advisory.

At the time of writing, this story is covered by one primary source only, the GitHub advisory. There is no CVE record in the research and no independent confirmation of impact beyond what the advisory describes. Details below are attributed to that advisory.

How the flaw works

The weakness is an integer wraparound. When imgproxy's ICO loader reads an icon file, it takes a 32-bit size value declared inside the file, then allocates memory for that size plus a small fixed header length. The advisory explains that for very large declared sizes this addition wraps around in 32-bit arithmetic, so the allocated buffer ends up tiny while the code still works with the originally declared size.

The loader then copies the bytes the file actually contains into that undersized allocation, at an offset that points past it. That corrupts the heap memory of the process. The advisory describes two outcomes, termination of the process handling the image (denial of service) and potentially remote code execution, and it does not rank their likelihood.

The advisory states that a network client can trigger this with attacker-controlled image bytes that begin with the ICO signature. This article does not reproduce the crafted values.

Who is exposed

The advisory's finding is that attacker-controlled image bytes reaching a vulnerable imgproxy over the network are enough. Whether that applies to you depends on how you deploy it. As general reasoning, not an advisory finding:

  • Instances that process images from sources an outsider can influence, such as visitor-supplied URLs or user uploads that are later resized, are the most obvious concern.
  • A CDN or proxy in front of imgproxy does not change the vulnerable code. Whether it shields you depends on whether untrusted image content can still reach imgproxy through it.
  • Instances that only process images you fully control have a smaller attack surface, but you should still upgrade.

The advisory gives the affected range as 4.0.0 up to but not including 4.0.16, and lists the /v2 and /v3 Go module paths with the same range. It says nothing about other versions, so check the maintainers' release notes if you run something older.

How to check your exposure

First find out which version you run. If imgproxy runs as a container, this lists local image tags on a Docker host. Look for tags in the 4.0.x range below 4.0.16.

List local imgproxy image tags on a Docker host (read-only)Shell
docker images | grep -i imgproxy

If you deploy through Kubernetes, this prints the images used by pods in all namespaces so you can spot imgproxy tags.

Show container images running in a Kubernetes cluster (read-only)Shell
kubectl get pods --all-namespaces -o jsonpath='{range .items[*]}{.metadata.namespace}{"\t"}{.metadata.name}{"\t"}{range .spec.containers[*]}{.image}{" "}{end}{"\n"}{end}' | grep -i imgproxy

If you build imgproxy from source or vendor it as a Go dependency, this searches your module file for the version in use. Run it in the project directory.

Find imgproxy in a Go project's dependencies (read-only)Shell
grep -i imgproxy go.mod

What to do now

Caution. Redeploying imgproxy briefly interrupts image delivery. Roll out during a quiet period or one instance at a time behind your load balancer.

To update a Docker-based deployment, pull the fixed tag and recreate the container using your normal process. Check the 4.0.16 release page for the exact image name and tag you use, rather than relying on a floating tag.

Detection and monitoring

The advisory does not publish indicators of compromise, and the research does not say the flaw is exploited. Monitoring is therefore a reasonable heuristic, not a known indicator: since one described outcome is process termination, repeated crashes or container restarts on an instance that is normally stable are worth investigating, as are ICO requests from unfamiliar sources.

On a Docker host, this read-only command shows each imgproxy container's status and uptime. A very short uptime on an instance that normally runs for days deserves a look at the logs.

Show imgproxy container status and uptime on a Docker host (read-only)Shell
docker ps -a --filter name=imgproxy --format '{{.Names}}\t{{.Status}}'

Uptime monitoring on the image endpoint also helps you notice crashes quickly; see uptime monitoring explained and Webforta Monitor. A website firewall may add a layer in front of image endpoints, but it is no substitute for upgrading.

Why this class of bug matters

Image decoders parse binary formats and rely on length fields stored in the file itself. When arithmetic on such a length wraps around, a program can allocate too little memory and then write too much into it. Keeping image-processing services patched, isolated and fed from trusted sources limits the damage when a flaw like this appears.

Sources

This article is based on the public sources below. Details can change as vendors and researchers publish more; check the original advisories before acting on version numbers.

  1. GHSA-hff9-5pqw-6w9f - GitHub Advisory Databasegithub.com ·
  • imgproxy
  • integer overflow
  • heap overflow
  • image processing
  • RCE
  • denial of service