Quick answers
- Is This vulnerability exploited in the wild?
- No. Junglewise Threat Intelligence has no report of This vulnerability being exploited in the wild.
- How severe is This vulnerability?
- High severity, with a CVSS score of 7.5, published 30 October 2026.
- Which products and versions are affected?
- github.com/imgproxy/imgproxy/v3 (Go) >= 3.3.0, < 4.0.17, SEMVER:introduced=3.3.0,fixed=4.0.17; Imgproxy 3.3.x through 4.0.15.
- Is there a fix for This vulnerability?
- Yes. github.com/imgproxy/imgproxy/v3 (Go): upgrade to 4.0.17 or later. Junglewise finds every place you run it, drafts the upgrade and applies it once you approve.
- How is This vulnerability attacked?
- It is attacked over the network, in a hosted service.
- Am I affected?
- Check whether you run github.com/imgproxy/imgproxy/v3 (Go) or Imgproxy at an affected version. Junglewise does that check for you around the clock: connect your code, cloud and domains, and it matches new vulnerabilities like this one against what you actually run and tells you when one reaches you.
How to fix
- github.com/imgproxy/imgproxy/v3 (Go): upgrade to 4.0.17 or later
go get github.com/imgproxy/imgproxy/v3@v4.0.17
Technical details
The vulnerability is an out-of-bounds heap write in vips/icoload.c during BMP header reconstruction. When processing an ICO entry with an undersized image data buffer, the loader reads unvalidated BITMAPINFOHEADER fields (num_colors, bpp, height) at fixed offsets that extend past the allocation, then writes a reconstructed 32-bit height value that corrupts the size field of the adjacent heap chunk. This corrupts the heap metadata such that the next free() deterministically triggers glibc's munmap_chunk() abort path, killing the imgproxy worker.
Affected products
- imgproxy imgproxy 3.3.x through 4.0.15
Timeline
- 2026-10-30: disclosed