Daily · Article 01 · 4 min read
- Security
- Open source
Three imgproxy flaws get CVE records. Check the running build
November 8 JST CVE registration · fixed releases published September 29 and October 1 JST
Summary
A false size label in an icon can corrupt an image server’s working memory. Separate the earlier fixes, the November 8 CVE records and actual deployment.
Key facts
If your site uses imgproxy to resize images, ask which version is processing requests in production and whether it can receive images supplied by outsiders. On November 8, three previously disclosed flaws in the software’s ICO icon reader were registered in the public CVE catalog. The maintainers had released v4.0.16 and v4.0.17 on September 29 and October 1 JST, respectively, and posted their advisories on October 7 JST (October 6 UTC). The new CVE records make those earlier fixes easier to track.
The most severe of the three can corrupt working memory and, under the advisory’s conditions, allow code to run on the image server. The records establish a vulnerability and its possible effects. Exploitation of a specific service requires separate evidence. CVE records · Maintainer advisory

1. When a thumbnail request reaches the image server
A shop might use imgproxy to retrieve a product photo and turn it into a small preview. The program reads the image format and its internal labels to determine what to unpack and how much working memory to reserve. ICO is a format commonly used for icons. In a fictional shop that accepts an outside seller’s image URL, a request for a preview can lead the server to fetch and open an ICO file chosen by that seller. Whether that route exists depends on the shop’s source restrictions and request controls.
One flaw occurs when the file claims an unusually large size. The reader adds space for a header, and the result wraps back to a small number, like a counter rolling over. On a fictional two-digit counter, adding 5 to 98 gives 103, but the display wraps to 03. The image reader uses a much larger limit, but the same kind of wrap leaves too little working space. When it starts copying the image bytes, they can extend into memory used for other work. A different flaw can reserve far too much memory and make the worker stop. Undersized allocation advisory · Excessive allocation advisory

The cat asks Q&A
- The researcher
How can an image file make a server run code?
Pocket NotebookA false size can make the server’s image reader write past the space it reserved. The maintainer lists a crash or code execution as possible consequences. The drawing follows that path, while excessive memory allocation is a separate failure.
2. The three advisories set different version boundaries
Each row gives the affected versions and the first version the maintainer identifies as fixed for that issue. A running v4.0.16 instance crosses the first two boundaries and still falls within the third affected range.
| Record and possible effect | Affected versions | First fixed version |
|---|---|---|
| CVE-2026-123614 · too little memory is reserved, leading to corruption, a crash or code execution | v4.0.0–v4.0.15 | v4.0.16 |
| CVE-2026-123616 · excessive reservation exhausts memory and can stop the worker | v3.3.0–v4.0.15 | v4.0.16 |
| CVE-2026-123615 · the reader accesses memory outside the reserved region, with a worker crash demonstrated in the advisory | v3.3.0–v4.0.16 | v4.0.17 |
- Record and possible effect
CVE-2026-123614 · too little memory is reserved, leading to corruption, a crash or code execution
- Affected versions
- v4.0.0–v4.0.15
- First fixed version
- v4.0.16
- Record and possible effect
CVE-2026-123616 · excessive reservation exhausts memory and can stop the worker
- Affected versions
- v3.3.0–v4.0.15
- First fixed version
- v4.0.16
- Record and possible effect
CVE-2026-123615 · the reader accesses memory outside the reserved region, with a worker crash demonstrated in the advisory
- Affected versions
- v3.3.0–v4.0.16
- First fixed version
- v4.0.17
The cat asks Q&A
- The researcher
The first two rows say fixed in v4.0.16. Is that enough for the three?
Pocket NotebookThe third row sets the higher boundary. Look for a supported build that includes the v4.0.17 fix and verify it on every worker handling live traffic. The release pages describe the supplier’s fixes, and your runtime records show what the service uses.
3. Track publication, deployment and earlier activity
| Stage | Status and owner | Evidence to inspect |
|---|---|---|
| Fixed releases | Confirmed · imgproxy maintainers | v4.0.16 release and v4.0.17 release |
| Public CVE entries | Confirmed · VulnCheck registered the entries on November 8 | 123614 · 123615 · 123616 |
| Fixed build serving requests | Verify per service · site or hosting operator | Running versions, container image identifiers if used, and rollout time |
| Prior activity | Investigate per service · security or operations team | Request sources, worker crashes or restarts, and the period during which affected versions accepted input |
- Stage
Fixed releases
- Status and owner
- Confirmed · imgproxy maintainers
- Evidence to inspect
- v4.0.16 release and v4.0.17 release
- Stage
Public CVE entries
- Status and owner
- Confirmed · VulnCheck registered the entries on November 8
- Stage
Fixed build serving requests
- Status and owner
- Verify per service · site or hosting operator
- Evidence to inspect
- Running versions, container image identifiers if used, and rollout time
- Stage
Prior activity
- Status and owner
- Investigate per service · security or operations team
- Evidence to inspect
- Request sources, worker crashes or restarts, and the period during which affected versions accepted input
The cat asks Q&A
- The researcher
Our deployment dashboard says it finished. What should I ask for?
Pocket NotebookAsk which build actually serves requests, when the last old worker was replaced and whether outside image URLs could reach it before then. Compare request and worker records over that earlier period. A crash can guide the investigation, but its cause needs evidence.
To close
Start with the image path and running build
Give the operator a concrete question: “Can a seller’s image reach our image processor, and which build handled it before and after the update?” That connects the advisory to the real service and gives the investigation a time window.
Sources
- 123614cve.org
- CVE-2026-123614github.com
- CVE-2026-123616github.com
- CVE-2026-123615github.com
- v4.0.16 releasegithub.com
- v4.0.17 releasegithub.com
- 123615cve.org
- 123616cve.org