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 has been updated to version 1.6.51, which contains fixes for security vulnerabilities including CVE-2025-65018 and CVE-2025-64720.

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.

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.

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 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. 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 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.

Last updated 18 August 2026

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.

DISPUTED pngcreateinfostruct in png.c in libpng 1.6.36 has a memory leak, as demonstrated by pngcp. NOTE: a third party has stated "I don't think it is libpng's job to free this buffer."

Hello, everyone,

This is an out-of-band notice. Unlike previous libpng announcements, this one doesn't coincide with a libpng release, and the disclosure cadence differs from the usual coordinated pattern:

- The fix landed on the libpng18 development branch (commit faf0692468) approximately one month before this announcement. libpng 1.8.0 is in late beta with no tagged release yet, so there is no upstream release version with which to align the disclosure. Downstream consumers building directly from the libpng18 branch have had the fix available since it landed. - The vulnerable code originates in the third-party libpng-apng patch, which is not under upstream libpng control. The patch is applied downstream by Firefox and Thunderbird, as well as several Linux distributions (Gentoo and LFS/BLFS among others). The libpng-apng maintainer, Daisuke Nishikawa, has since released fixed revisions (libpng-1.6.57-apng.patch v2 and libpng-1.6.58-apng.patch); downstream consumers should either update to those (verifying that both upstream commits are included), or backport the upstream commits themselves (see "Related fix" below).

=== CVE-2026-40930 ===

Chunk smuggling in the push-mode APNG parser via unconsumed chunk body

Security advisory: https://github.com/pnggroup/libpng/security/advisories/GHSA-c4v6-gxrq-6g2x

Fix on libpng18: https://github.com/pnggroup/libpng/commit/faf06924688b62d7c1654b5ceddedbde66ffadb4

CVSS 3.1: 5.4 (Medium); CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:L/A:L CWE: CWE-436 (Interpretation Conflict) Affected (upstream): libpng 1.8.0 development branch (libpng18) Affected (downstream): libpng-1.6.49-apng.patch through libpng-1.6.57-apng.patch (original v1) on SourceForge Not affected: upstream libpng 1.6.x releases (no APNG support) Fixed (upstream): libpng18 at commit faf0692468 Fixed (downstream): libpng-1.6.57-apng.patch v2 and libpng-1.6.58-apng.patch on SourceForge, released by the libpng-apng maintainer Build-time mitigation: building libpng 1.8 with APNG disabled (i.e., without PNGAPNGSUPPORTED), or building libpng 1.6 without the libpng-apng patch, removes the vulnerable code. No runtime workaround exists for push-mode applications.

Three inter-frame chunk discard paths in the push-mode APNG parser clear the chunk-header flag without consuming the chunk body and CRC, allowing attacker-controlled bytes inside a discarded chunk to be reinterpreted as a fresh chunk header on the next call to pngprocessdata.

Impact depends on the application's CRC handling:

- Default configuration: libpng calls pngerror on the resulting CRC mismatch or APNG sequence-number violation, and the image fails to load. Impact is denial of service. - Relaxed configuration (pngsetcrcaction with PNGCRCQUIETUSE or PNGCRCWARNUSE): smuggled bytes reach the APNG sequence counter and the zlib decompressor, and are decoded as frame pixel data. No code execution: zlib output writes into a pre-allocated row buffer. A crafted fake length exceeding the carrier chunk body causes cascading desynchronization beyond the carrier.

Sequential-mode reading (pngreadinfo / pngreadrow / pngreadend) is not affected. Only push-mode (pngprocessdata) is vulnerable, and the Gecko-based browsers (for example) use it.

=== Related fix ===

A sibling defect in the same push-mode fdAT path was reported separately in GitHub issue pnggroup/libpng#854 and fixed on the libpng18 branch in commit 9ec49c2d56. It is distinct from CVE-2026-40930 and is not covered by the advisory above. Downstream consumers of libpng-apng should apply both commits to fully remediate the push-mode fdAT path. Those updating to the fixed libpng-apng revisions instead should verify that both commits are included; otherwise, 9ec49c2d56 must be backported separately.

Related fix on libpng18: https://github.com/pnggroup/libpng/commit/9ec49c2d56cec19107ddc458b648ce224c9697b3

Credits: - Seung Min Shin (CVE-2026-40930 discovery) - Ryo Shimada (GitHub issue pnggroup/libpng#854)

--- Cosmin Truta libpng maintainer

Multiple integer overflows in libpng before 1.5.14rc03 allow remote attackers to cause a denial of service (crash) via a crafted image to the (1) pngsetsPLT or (2) pngsettext2 function, which triggers a heap-based buffer overflow.