libpng 1.6.55 is public, because we've been hit again

Cosmin Truta <[email protected]> Tue, 10 Feb 2026 02:29:20 +0200
Newsgroups gmane.comp.graphics.png.announce
Message-ID <CAAoVtZxRwTtcoH8h1JGb49AO6bsZ8PPbWQy4g_0YpUs_fmy_yA@mail.gmail.com>
--===============2585184858449286920==
Content-Type: multipart/alternative; boundary="000000000000581cad064a6d59e3"

--000000000000581cad064a6d59e3
Content-Type: text/plain; charset="UTF-8"

Hello, everyone,

Yep, it's another security release. Nope, I'm not happy about it either.
And yet, here we are, and here is libpng-1.6.55.

CVE-2026-25646 is a heap buffer overflow in png_set_quantize, the function
that reduces the number of colors in a palette. A logic error in the color
distance table, storing current palette indices where the rest of the code
expects original indices, causes the pruning loop to lose track of valid
candidates after colors get swapped. The search bound then grows past the
end of an internal heap buffer, and out-of-bounds reads occur. The
triggering images are valid per the PNG specification. The bug has existed
since the initial version of this function, back when it was still called
png_set_dither.

I mean...

That's about 30 years! In our defense, the code in question has been
sitting under a comment that literally says *"We don't understand this at
all, so if someone wants to work on improving it, be our guest."* Well,
Joshua Inscoe was our guest -- and he delivered!

Unlike the CVEs fixed in 1.6.51, 1.6.52 and 1.6.54, which all affected the
simplified API, this one is in the low-level API. If you use
png_set_quantize to reduce the number of colors in untrusted PNG images,
you need this update.

Many thanks to Joshua for reporting this issue, for analyzing it
thoroughly, AND for handing us the fix. Some of the best patches can be
printed on a business card, and this is one of those :-)

The gory details are available at:
https://github.com/pnggroup/libpng/security/advisories/GHSA-g8hp-mq4h-rqm3
https://www.openwall.com/lists/oss-security/2026/02/09/7

---

Also in this release: Philippe Antoine resolved an oss-fuzz build issue
involving nalloc.

---

In the good old tradition of file authentication, here are the SHA-2-256
checksums of the published archive files:

libpng-1.6.55.tar.gz
4b0abab6d219e95690ebe4db7fc9aa95f4006c83baaa022373c0c8442271283d

libpng-1.6.55.tar.xz
d925722864837ad5ae2a82070d4b2e0603dc72af44bd457c3962298258b8e82d

lpng1655.7z
12216980290bc4b5dc3e8914865f983a1b0739d6400573760ed953fedd098a6a

lpng1655.zip
aa45ef52ff7a4e61f34af866b3254b0b243ddc42fe2adb823b0843d2a57c2e86

Sincerely,
Cosmin

--000000000000581cad064a6d59e3
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Hello, everyone,<br><br>Yep, it&#39;s another security rel=
ease. Nope, I&#39;m not happy about it either. And yet, here we are, and he=
re is libpng-1.6.55.<br><br>CVE-2026-25646 is a heap buffer overflow in png=
_set_quantize, the function that reduces the number of colors in a palette.=
 A logic error in the color distance table, storing current palette indices=
 where the rest of the code expects original indices, causes the pruning lo=
op to lose track of valid candidates after colors get swapped. The search b=
ound then grows past the end of an internal heap buffer, and out-of-bounds =
reads occur. The triggering images are valid per the PNG specification. The=
 bug has existed since the initial version of this function, back when it w=
as still called png_set_dither.<br><br>I mean...<br><br>That&#39;s about 30=
 years! In our defense, the code in question has been sitting under a comme=
nt that literally says <i>&quot;We don&#39;t understand this at all, so if =
someone wants to work on improving it, be our guest.&quot;</i> Well, Joshua=
 Inscoe was our guest -- and he delivered!<br><br>Unlike the CVEs fixed in =
1.6.51, 1.6.52 and 1.6.54, which all affected the simplified API, this one =
is in the low-level API. If you use png_set_quantize to reduce the number o=
f colors in untrusted PNG images, you need this update.<br><br>Many thanks =
to Joshua for reporting this issue, for analyzing it thoroughly, AND for ha=
nding us the fix. Some of the best patches can be printed on a business car=
d, and this is one of those :-)<br><br>The gory details are available at:<b=
r><a href=3D"https://github.com/pnggroup/libpng/security/advisories/GHSA-g8=
hp-mq4h-rqm3">https://github.com/pnggroup/libpng/security/advisories/GHSA-g=
8hp-mq4h-rqm3</a><br><a href=3D"https://www.openwall.com/lists/oss-security=
/2026/02/09/7">https://www.openwall.com/lists/oss-security/2026/02/09/7</a>=
<br><div><br></div><div>---</div><div><br></div>Also in this release: Phili=
ppe Antoine resolved an oss-fuzz build issue involving nalloc.<br><div><br>=
</div><div>---</div><div><br></div>In the good old tradition of file authen=
tication, here are the SHA-2-256 checksums of the published archive files:<=
br><br>libpng-1.6.55.tar.gz<br>4b0abab6d219e95690ebe4db7fc9aa95f4006c83baaa=
022373c0c8442271283d<br><br>libpng-1.6.55.tar.xz<br>d925722864837ad5ae2a820=
70d4b2e0603dc72af44bd457c3962298258b8e82d<br><br>lpng1655.7z<br>12216980290=
bc4b5dc3e8914865f983a1b0739d6400573760ed953fedd098a6a<br><br>lpng1655.zip<b=
r>aa45ef52ff7a4e61f34af866b3254b0b243ddc42fe2adb823b0843d2a57c2e86<br><br>S=
incerely,<br>Cosmin</div>

--000000000000581cad064a6d59e3--


--===============2585184858449286920==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline


--===============2585184858449286920==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
png-mng-announce mailing list
png-mng-announce-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
https://lists.sourceforge.net/lists/listinfo/png-mng-announce

--===============2585184858449286920==--