Skip to main content
← All vulnerabilities
GHSA-HFF9-5PQW-6W9F

imgproxy has integer overflow in imgproxy ICO loader that causes denial of service and may permit remote code execution

Only affects imgproxy 4.0.0 through 4.0.15 when processing crafted ICO images. Fixed in 4.0.16.

Published
Last modified
published
Not listed in CISA KEV
Unclear
Critical (ghsa)
Fix
Fixed in 4.0.16
None on Exploit-DB, Metasploit or GitHub

Summary

imgproxy, an image processing server, is affected in its ICO image loader, which is used when it processes ICO-format images. A remote attacker who sends a specially crafted ICO file can cause a memory corruption flaw that may crash the service (denial of service) and could potentially allow remote code execution.

Summarized by anthropic/claude-haiku-5.5. Verify details against the original sources.

Read the original description

The ICO loader allocates `data_size + BMP_FILE_HEADER_LEN` bytes after reading a 32-bit attacker-controlled `data_size`. For `data_size > UINT32_MAX - BMP_FILE_HEADER_LEN`, the addition wraps before allocation. imgproxy then writes the ICO prefix and reads up to the original declared size starting 14 bytes into the undersized allocation. A network client can turn this heap overflow into remote denial of service or remote code execution. Technical details The vulnerable path is in `vips/icoload.c` at commit `f4fedbb`: ```c uint32_t data_size = GUINT32_FROM_LE(largest_image_header.data_size); VipsPel data = (VipsPel ) VIPS_MALLOC(NULL, data_size + BMP_FILE_HEADER_LEN); void *actual_data = data + BMP_FILE_HEADER_LEN; if (vips_foreign_load_read_full(ico->source, actual_data, data_size) <= 0) { vips_error("vips_foreign_load_ico_header", "unable to read ICO image data from the source"); return -1; } ``` The crafted directory entry contains: ```text data_size = 0xfffffff5 (4294967285) data_offset = 22 BMP header size = 14 32-bit result = (0xfffffff5 + 14) mod 2^32 = 3 ``` The allocation is therefore three bytes. `actual_data` points 14 bytes after the allocation base. The fixture contains 64 bytes after the ICO header, so the source callback copies those 64 bytes to an invalid destination before it can report that the declared multi-gigabyte payload is incomplete. The complete source-to-sink path is: 1. Attacker-controlled bytes begin with the ICO magic `00 00 01 00`. 2. imgproxy identifies the source as ICO and dispatches it to `vips_icoload_source_go`. 3. `vips_foreign_load_ico_header` reads the attacker-controlled `data_size`. 4. The 32-bit addition wraps, and `VIPS_MALLOC` receives the value three. 5. `vips_foreign_load_read_full` passes the original `data_size` to the Go source callback. 6. The callback writes the available source bytes through the invalid pointer, corrupting the process heap. Impact A crafted image can terminate the imgproxy process handling it or potentially lead to remote code execution due to heap corruption.

Timeline

  1. Advisory published
  2. Record last updated
  3. First seen by cve.now

Affected versions

  • github.com/imgproxy/imgproxy/v3Go

    From 4.0.0 · fixed in 4.0.16

  • github.com/imgproxy/imgproxy/v2Go

    From 4.0.0 · fixed in 4.0.16

  • github.com/imgproxy/imgproxyGo

    From 4.0.0 · fixed in 4.0.16

References 4

GitHub · imgproxy/imgproxy

FAQ

Questions about GHSA-HFF9-5PQW-6W9F

What does this mean?

A crafted ICO image triggers an integer overflow in imgproxy's ICO loader. The imgproxy process handling the image can be terminated, and the overflow may also cause heap corruption that could lead to remote code execution.Source: github.com, github.com

Am I affected, and how do I check?

Affected are imgproxy v4 versions from 4.0.0 through 4.0.15 that process ICO images through the ICO loader. Compare the imgproxy version in use against this range to check whether it falls inside it.Source: github.com, github.com

What should I do about it?

Upgrade imgproxy to 4.0.16 or later, which contains the fix.Source: github.com, github.com

Is it being exploited?

It is not in CISA's Known Exploited Vulnerabilities catalog, and CISA's SSVC assessment does not mark exploitation as active. That does not mean it has not been attacked: vendors and researchers can report attacks before CISA lists them. No public exploit code is tracked.Source: cve.now feed data