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.
- Last modified
- Where the record stands: published, rejected by its publisher, or superseded by another id.What do these mean? →
- published
- Whether CISA lists it in its Known Exploited Vulnerabilities catalog: proof that attackers are using it.What do these mean? →
- Not listed in CISA KEV
- How many real-world setups can hit the bug, from the vendor's advisory and CISA data. It does not know your setup.What do these mean? →
- Unclear
- The rating the maker of the software gives it. Shown when it differs from the CVSS level.What do these mean? →
- Critical (ghsa)
- Fix
- Fixed in 4.0.16
- Whether working attack code is public (Exploit-DB, Metasploit, Nuclei or GitHub). Public code makes attacks easier.What do these mean? →
- 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
- Advisory published
- Record last updated
- 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
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