Bob Friesenhahn

CVE-2026-33535

Record that this issue is fixed.

A fix for the buffer overflow issue is submitted by Mercurial changeset 18020:df03dfbf4d4b. Only up to 10 digits are collected at a time, and any failure to convert the digits to an integer resets back to the default state.

It seems that the ImageMagick6 patch referred to is incomplete. The problem is not that 'delta' is too short, rather, the problem seems to be that a nul byte may be written beyond the boundary of 'delta', which is statically allocated. The current code has much more implementation such as to ignore requests which would overflow the boundary of 'delta'. This existing line of GraphicsMagick code is humorous: delta[strlen(delta)+1]='\0'; Ultimately, the goal is that the 'delta' string is turned into...

CVE-2026-28690

Change set 18010:967c71e2b740 provides necessary error handling for ImageToBlob(), as well as to assure that no more than 256 colors will be supplied to the MNG PLTE chunk.

If CVEs provided adequate and complete descriptions of an issue, then the information could be used to immediately attack existing code. So they use vague obtuse descriptions which mean almost nothing. Based on the last part of the ImageMagick edits, there may have been an overflow of the image colormap.

I did a search and see that CVE-2026-28690 is about a MNG encoder stack buffer overflow rather than a use of a null pointer in the JNG encoder. The ImageMagick project may have made other fixes while claiming to address CVE-2026-28690. It would be useful to know the details about where this stack buffer overflow happens. Are you able to determine this? I do recall solving several MNG stack overflow issues in the past.