Cosmin Truta <ctruta () gmail com> writes: Hello, everyone, Hi Cosmin, libpng 1.6.59 has been released, fixing a medium-severity use-after-free vulnerability in the sequential reader, present since libpng 1.6.0. It affects applications that call pngreadend without first starting to read the image rows.

Users should either upgrade to libpng 1.6.59 or apply the fix described below.

[...] I can't find a tarball for libpng-1.6.59 in the usual places: https://sourceforge.net/projects/libpng/files/libpng16/ has no 1.6.59 dir and http://libpng.download/src linked from the README in the repo has no recent releases.

Is there a plan to make an official tarball available, or to use the GitHub autogenerated ones going forward? The latter is unfortunate if so because they're not guaranteed to be stable (and can't be signed, though libpng releases aren't signed at the moment; was going to file a bug asking about that).

Cheers! sam

Hello, everyone,

libpng 1.6.59 has been released, fixing a medium-severity use-after-free vulnerability in the sequential reader, present since libpng 1.6.0. It affects applications that call pngreadend without first starting to read the image rows.

Users should either upgrade to libpng 1.6.59 or apply the fix described below.

=== CVE-2026-46675 ===

Use-after-free of zlib input in pngreadend after incomplete zTXt, iTXt or iCCP decompression

Security advisory: https://github.com/pnggroup/libpng/security/advisories/GHSA-qvg3-h654-xq3j

Fix: https://github.com/pnggroup/libpng/commit/aa77ef38c17ab2fc1b41bec09fb973c6a386641d

CVSS 3.1: 5.9 (Medium) - CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:H CWE: CWE-416 (Use After Free), CWE-825 (Expired Pointer Dereference) Affected: libpng 1.6.0 through 1.6.58 Fixed: libpng 1.6.59

A crafted zTXt, iTXt or iCCP chunk can make libpng abandon decompression while zlib still expects more input: for example, with an invalid window size in the zlib header, with decompressed data too large for libpng to accept, or with an ICC profile that fails validation. The chunk handlers released the zlib stream without clearing its input pointer and count. If the application then calls pngreadend after pngreadinfo, without first starting to read the image rows, pngreadend resumes decompression from that stale pointer instead of reading the IDAT data.

- zTXt and iTXt: the pointer refers to libpng's chunk read buffer, which a later, larger chunk before IDAT (tEXt or pCAL, for example) frees and reallocates; the read is a heap use-after-free. - iCCP: the pointer refers to local arrays of pnghandleiCCP; the read is a stack use-after-return.

Impact: - The dangling pointer is only read, and the decompressed bytes go to a scratch buffer that is discarded, so no data is disclosed or corrupted. - The worst outcome is a crash in the heap variant, when the freed memory is no longer mapped at the time of the read. - The affected call sequence is rare in practice: pngreadend called this way parses the unread image data as chunks, and fails with a libpng error on well-formed files; the stale read happens before that error.

Workaround: Do not call pngreadend when the image rows are not read. If the chunks after the image data are needed, call pngstartreadimage before pngreadend. Whether upgraded or not, applications that call pngreadend without reading the image rows should be prepared to handle a libpng error from it.

Credits: - Ze Sheng, O2Lab and AISLE - @JasonHonKL (independent report of the iCCP variant)

=== References ===

- Release: https://github.com/pnggroup/libpng/releases/tag/v1.6.59 - Independent report: https://github.com/pnggroup/libpng/issues/855 - libpng homepage: http://www.libpng.org/pub/png/libpng.html

--- Cosmin Truta libpng maintainer

Last updated 18 August 2026

LIBPNG is a reference library for use in applications that read, create, and manipulate PNG (Portable Network Graphics) raster image files. Prior to 1.6.55, an out-of-bounds read vulnerability exists in the pngsetquantize() API function. When the function is called with no histogram and the number of colors in the palette is more than twice the maximum supported by the user's display, certain palettes will cause the function to enter into an infinite loop that reads past the end of an internal heap-allocated buffer. The images that trigger this vulnerability are valid per the PNG specification. This vulnerability is fixed in 1.6.55.

Last updated 18 August 2026

Last updated 18 August 2026

LIBPNG is a reference library for use in applications that read, create, and manipulate PNG (Portable Network Graphics) raster image files. In versions 1.6.36 through 1.6.55, an out-of-bounds read and write exists in libpng's ARM/AArch64 Neon-optimized palette expansion path. When expanding 8-bit paletted rows to RGB or RGBA, the Neon loop processes a final partial chunk without verifying that enough input pixels remain. Because the implementation works backward from the end of the row, the final iteration dereferences pointers before the start of the row buffer (OOB read) and writes expanded pixel data to the same underflowed positions (OOB write). This is reachable via normal decoding of attacker-controlled PNG input if Neon is enabled. Version 1.6.56 fixes the issue.

LIBPNG is a reference library for use in applications that read, create, and manipulate PNG (Portable Network Graphics) raster image files. In versions 1.2.1 through 1.6.55, pngsettRNS and pngsetPLTE each alias a heap-allocated buffer between pngstruct and pnginfo, sharing a single allocation across two structs with independent lifetimes. The transalpha aliasing has been present since at least libpng 1.0, and the palette aliasing since at least 1.2.1. Both affect all prior release lines pngsettRNS sets pngptr->transalpha = infoptr->transalpha (256-byte buffer) and pngsetPLTE sets infoptr->palette = pngptr->palette (768-byte buffer). In both cases, calling pngfreedata (with PNGFREETRNS or PNGFREEPLTE) frees the buffer through infoptr while the corresponding pngptr pointer remains dangling. Subsequent row-transform functions dereference and, in some code paths, write to the freed memory. A second call to pngsettRNS or pngsetPLTE has the same effect, because both functions call pngfreedata internally before reallocating the infoptr buffer. Version 1.6.56 fixes the issue.

LIBPNG is a reference library for use in applications that read, create, and manipulate PNG (Portable Network Graphics) raster image files. Prior to 1.6.55, an out-of-bounds read vulnerability exists in the pngsetquantize() API function. When the function is called with no histogram and the number of colors in the palette is more than twice the maximum supported by the user's display, certain palettes will cause the function to enter into an infinite loop that reads past the end of an internal heap-allocated buffer. The images that trigger this vulnerability are valid per the PNG specification. This vulnerability is fixed in 1.6.55.

LIBPNG has an integer truncation causing heap buffer over-read in pngimagewrite

LIBPNG is a reference library for use in applications that read, create, and manipulate PNG (Portable Network Graphics) raster image files. From 1.6.51 to 1.6.53, there is a heap buffer over-read in the libpng simplified API function pngimagefinishread when processing interlaced 16-bit PNGs with 8-bit output format and non-minimal row stride. This is a regression introduced by the fix for CVE-2025-65018. This vulnerability is fixed in 1.6.54.

LIBPNG is a reference library for use in applications that read, create, and manipulate PNG (Portable Network Graphics) raster image files. From 1.6.26 to 1.6.53, there is an integer truncation in the libpng simplified write API functions pngwriteimage16bit and pngwriteimage8bit causes heap buffer over-read when the caller provides a negative row stride (for bottom-up image layouts) or a stride exceeding 65535 bytes. The bug was introduced in libpng 1.6.26 (October 2016) by casts added to silence compiler warnings on 16-bit systems. This vulnerability is fixed in 1.6.54.

LIBPNG is a reference library for use in applications that read, create, and manipulate PNG (Portable Network Graphics) raster image files. From 1.6.51 to 1.6.53, there is a heap buffer over-read in the libpng simplified API function pngimagefinishread when processing interlaced 16-bit PNGs with 8-bit output format and non-minimal row stride. This is a regression introduced by the fix for CVE-2025-65018. This vulnerability is fixed in 1.6.54.

LIBPNG is a reference library for use in applications that read, create, and manipulate PNG (Portable Network Graphics) raster image files. From version 1.6.0 to before 1.6.51, an out-of-bounds read vulnerability exists in pngimagereadcomposite when processing palette images with PNGFLAGOPTIMIZEALPHA enabled. The palette compositing code in pnginitreadtransformations incorrectly applies background compositing during premultiplication, violating the invariant component ≤ alpha × 257 required by the simplified PNG API. This issue has been patched in version 1.6.51.

Libpng has been updated to version 1.6.51, which contains fixes for security vulnerabilities including CVE-2025-65018 and CVE-2025-64720.

LIBPNG has an out-of-bounds read in pngimagereadcomposite

LIBPNG is a reference library for use in applications that read, create, and manipulate PNG (Portable Network Graphics) raster image files. Prior to 1.6.52, an out-of-bounds read vulnerability in libpng's simplified API allows reading up to 1012 bytes beyond the pngsRGBbase[512] array when processing valid palette PNG images with partial transparency and gamma correction. The PNG files that trigger this vulnerability are valid per the PNG specification; the bug is in libpng's internal state management. Upgrade to libpng 1.6.52 or later.

LIBPNG is a reference library for use in applications that read, create, and manipulate PNG (Portable Network Graphics) raster image files. From version 1.6.0 to before 1.6.51, there is a heap buffer overflow vulnerability in the libpng simplified API function pngimagefinishread when processing 16-bit interlaced PNGs with 8-bit output format. Attacker-crafted interlaced PNG files cause heap writes beyond allocated buffer bounds. This issue has been patched in version 1.6.51.

LIBPNG is a reference library for use in applications that read, create, and manipulate PNG (Portable Network Graphics) raster image files. From version 1.6.0 to before 1.6.51, an out-of-bounds read vulnerability exists in pngimagereadcomposite when processing palette images with PNGFLAGOPTIMIZEALPHA enabled. The palette compositing code in pnginitreadtransformations incorrectly applies background compositing during premultiplication, violating the invariant component ≤ alpha × 257 required by the simplified PNG API. This issue has been patched in version 1.6.51.

802.1X. An authentication issue was addressed with improved state management.

A use-after-free vulnerability was discovered in the pngimagefree function in the libpng library. This could lead to denial of service or a potentially exploitable crash when a malformed image is processed.

An issue has been found in libpng 1.6.34. It is a SEGV in the function pngfreedata in png.c, related to the recommended error handling for pngreadimage.

In libpng 1.6.34, a wrong calculation of rowfactor in the pngcheckchunklength function (pngrutil.c) may trigger an integer overflow and resultant divide-by-zero while processing a crafted PNG file, leading to a denial of service.

Last updated 18 August 2026

The pngpushreadchunk function in pngpread.c in the progressive decoder in libpng 1.6.x through 1.6.9 allows remote attackers to cause a denial of service (infinite loop and CPU consumption) via an IDAT chunk with a length of zero.

libpng 1.6.8 was released [1] and notes the following fix:

Handle zero-length PLTE chunk or NULL palette with pngerror() instead of pngchunkreport(), which by default issues a warning rather than an error, leading to later reading from a NULL pointer (pngptr->palette) in pngdoexpandpalette(). This is CVE-2013-6954 and VU#650142.

The git commit to fix is available [3].

[1] http://sourceforge.net/projects/libpng/files/libpng16/1.6.8/Gnupg/ [2] http://www.kb.cert.org/vuls/id/650142 [3] http://sourceforge.net/p/libpng/code/ci/1faa6ff32c648acfe3cf30a58d31d7aebc24968c

The PNG reference library (aka libpng) before 1.0.43, and 1.2.x before 1.2.35, as used in pngcrush and other applications, allows context-dependent attackers to cause a denial of service (application crash) or possibly execute arbitrary code via a crafted PNG file that triggers a free of an uninitialized pointer in (1) the pngreadpng function, (2) pCAL chunk handling, or (3) setup of 16-bit gamma tables.

Memory leak in the pnghandletEXt function in pngrutil.c in libpng before 1.2.33 rc02 and 1.4.0 beta36 allows context-dependent attackers to cause a denial of service (memory exhaustion) via a crafted PNG file.

The pngcheckkeyword function in pngwutil.c in libpng before 1.0.42, and 1.2.x before 1.2.34, might allow context-dependent attackers to set the value of an arbitrary memory location to zero via vectors involving creation of crafted PNG files with keywords, related to an implicit cast of the '\0' character constant to a NULL pointer. NOTE: some sources incorrectly report this as a double free vulnerability.