KEVWire

Security intelligence, with context.

Response snapshot Oct 31, 2026, 01:26 UTC

Back to the wire
Permalink
VulnerabilityGHSA-mmq5-xm89-9pfg

imgproxy has unbounded memory allocation in ICO loader that allows unauthenticated memory-exhaustion DoS via crafted data_size field

Unbounded and unvalidated memory allocation in imgproxy's ICO loader (vips/icoload.c).

At a glance

Exploited
Not known
Severity
Not scored yet
Chance of exploitation
Not estimated
Sources
1 source

What to do

GitHub lists first patched versions: github.com/imgproxy/imgproxy/v3: 4.0.16. Confirm the affected range and upgrade guidance in the exact advisory.

Read GitHub-reviewed advisory GHSA-mmq5-xm89-9pfg (opens a new tab)

What happened

Summary

Unbounded and unvalidated memory allocation in imgproxy's ICO loader (vips/icoload.c). An attacker-controlled data_size field (u32) from the ICO directory entry is passed directly to VIPS_MALLOC without any bounds check, so a single crafted 23-byte ICO file makes an imgproxy worker attempt a ~4GB allocation. Present in the latest release (v4.0.15) and the 3.3.x series; confirmed on a live production deployment of imgproxy v4.0.15.

Details

In vips_foreign_load_ico_header in vips/icoload.c, the selected directory entry's data_size is read and used directly for the allocation:

Continue reading
uint32_t data_size = GUINT32_FROM_LE(largest_image_header.data_size);

// BMP file explicitly excludes BITMAPFILEHEADER, so we need to add it manually.
VipsPel *data = (VipsPel *) VIPS_MALLOC(NULL, data_size + BMP_FILE_HEADER_LEN);

There is no validation that data_size is sane nor any check that the file actually contains data_size bytes at the declared data_offset. A crafted 23-byte ICO whose directory entry declares data_size = 0xfa000068 (~4GB) drives VIPS_MALLOC(NULL, ~4GB + 14).

PoC

# make_ico_4gb.py — generates the exact 23-byte unbounded-allocation trigger.
# Byte-identical to the checksummed, production-verified file:
# ico-4gb.ico sha256 6cee1fbfdc69fd4f507e86835ce2fa54519e55608f1dd69f42860f9961b1045b
import struct, hashlib

hdr = struct.pack(' HTTP 500 (worker survives, but each request burns ~4GB
# transiently — repeatable memory exhaustion).

Impact

Unauthenticated network DoS / memory-exhaustion: on memory-constrained workers, a crash per crafted request. On larger hosts, ~4GB transient allocation per request (sustained firing exhausts memory or the allocation budget). Any imgproxy deployment that processes attacker-supplied images.

Affected package ranges reported by GitHub: github.com/imgproxy/imgproxy/v3: >= 3.3.0, <= 4.0.15

Related technology

Sources

  1. Primary source

    GitHub-reviewed advisory GHSA-mmq5-xm89-9pfg (opens a new tab)

    The public advisory supplies the description, affected package/version ranges, and any listed CVSS metric. GitHub review is not local review.

    Published Checked

  2. Primary source

    GitHub public advisory API page (opens a new tab)

    The API page supplied GHSA-mmq5-xm89-9pfg, its actual identifiers, source dates, and structured metrics.

    Published Date not suppliedChecked

Cite this record

For factual claims, cite the primary sources above; cite KEVWire for its compilation, dates, and classifications.

APA

KEVWire. (2026, October 30). imgproxy has unbounded memory allocation in ICO loader that allows unauthenticated memory-exhaustion DoS via crafted data_size field. https://kevwire.com/record/GHSA-mmq5-xm89-9pfg

MLA

"imgproxy has unbounded memory allocation in ICO loader that allows unauthenticated memory-exhaustion DoS via crafted data_size field." KEVWire, 30 Oct. 2026, kevwire.com/record/GHSA-mmq5-xm89-9pfg.

Chicago

KEVWire. "imgproxy has unbounded memory allocation in ICO loader that allows unauthenticated memory-exhaustion DoS via crafted data_size field." Last modified October 30, 2026. https://kevwire.com/record/GHSA-mmq5-xm89-9pfg.

Evidence summary (plain text)

imgproxy has unbounded memory allocation in ICO loader that allows unauthenticated memory-exhaustion DoS via crafted data_size field (Oct 30, 2026).
Unbounded and unvalidated memory allocation in imgproxy's ICO loader (vips/icoload.c). An attacker-controlled data_size field (u32) from the ICO directory entry is passed directly to VIPS_MALLOC without any bounds check, so a single crafted 23-byte ICO file makes an imgproxy worker attempt a ~4GB allocation. Present in the latest release (v4.0.15) and the 3.3.x series; confirmed on a live production deployment of imgproxy v4.0.15.
Sources:
GitHub-reviewed advisory GHSA-mmq5-xm89-9pfg: https://github.com/advisories/GHSA-mmq5-xm89-9pfg
GitHub public advisory API page: https://api.github.com/advisories?type=reviewed&per_page=100&sort=updated&direction=desc
Record ID: GHSA-mmq5-xm89-9pfg.
Record origin: Ingested record.
AI evidence: Not assessed.
Known exploitation: Not assessed.
Zero-day status: Not assessed. KEV membership alone does not establish zero-day status.
About this data

This record was ingested from a data source. Retrieved: Oct 31, 2026, 00:50 UTC. Ingestion is not an independent editorial investigation.

A CISA KEV listing documents known exploitation, not necessarily a zero-day; absence from the catalog does not prove a vulnerability has never been exploited.

Technology tags indicate possible relevance, not verified exposure. Confirm the affected product, version, and configuration against your own inventory; KEVWire does not scan your systems.

A personal reading checklist on this device, not verified remediation.

Record JSON

Your account

Email alerts

Email alerts are coming as part of KEVWire Premium: join the waitlist. To follow your stack today, use its RSS feed, which honors your filters, or connect an AI agent through the API.

Suggest an improvement

Ideas, missing sources, corrections, and bugs are all welcome. No account needed. Suggestions are reviewed by a person before anything changes.

Record details

Record detail