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

Last updated 18 August 2026

Hello, everyone,

libpng 1.6.57 has been released, fixing a medium-severity use-after-free vulnerability in the chunk setter API, including a long-standing defect in pngsethIST present since at least 1.0.9 and regressions in pngsetPLTE and pngsettRNS introduced in 1.6.56.

Users should either upgrade to libpng 1.6.57 or apply the fixes described below.

=== CVE-2026-34757 ===

Use-after-free in pngsetPLTE, pngsettRNS and pngsethIST leading to corrupted chunk data and potential heap information disclosure

Security advisory: https://github.com/pnggroup/libpng/security/advisories/GHSA-6fr7-g8h7-v645

Fixes: https://github.com/pnggroup/libpng/commit/398cbe3df03f4e11bb031e07f416dfdde3684e8a https://github.com/pnggroup/libpng/commit/55d20aaa322c9274491cda82c5cd4f99b48c6bcc

CVSS 3.1: 5.1 (Medium) - CVSS:3.1/AV:L/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:N CWE: CWE-416 (Use-After-Free) Affected (pngsetPLTE, pngsettRNS): libpng 1.6.56 only Affected (pngsethIST): all versions since at least libpng 1.0.9 Fixed: libpng 1.6.57

Passing a pointer obtained from pnggetPLTE, pnggettRNS, or pnggethIST back into the corresponding setter on the same pngstruct/pnginfo pair causes the setter to free the internal buffer before copying from the caller-supplied pointer, which now dangles. The subsequent copy reads from freed memory, producing corrupted chunk data or leaking unrelated heap contents into the chunk struct.

The pngsetPLTE and pngsettRNS defects are regressions introduced by the CVE-2026-33416 fix in libpng 1.6.56; earlier versions tolerated the aliased pointer by accident. The pngsethIST defect has been present since at least libpng 1.0.9.

The defect cannot be triggered by a crafted PNG file alone; it requires the application to call the getter and setter in sequence on the same struct pair. Any valid image carrying the relevant chunk suffices to populate the internal pointer that the application then aliases.

Impact: - Corrupted chunk data: the setter copies stale or reallocated heap contents into the replacement buffer, silently corrupting chunk metadata - Information disclosure: unrelated heap data may become visible through subsequent getter calls

The same release also hardens the append-style setters (pngsettext, pngsetsPLT, pngsetunknownchunks) against a theoretical variant of the same aliasing pattern.

Workaround: applications that pass a getter's return value back to the corresponding setter on the same struct pair can simply remove the redundant setter call, or copy the getter's output into a caller-owned buffer before passing it to the setter.

Credits: - @Iv4n550 (discovery of PLTE and tRNS defects) - Cosmin Truta (discovery of hIST defect and fix of all defects)

=== References ===

- Release: https://github.com/pnggroup/libpng/releases/tag/v1.6.57 - libpng homepage: http://www.libpng.org/pub/png/libpng.html

--- Cosmin Truta libpng maintainer

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.

Last updated 18 August 2026

Last updated 18 August 2026

Hello, everyone,

libpng 1.6.56 has been released, fixing two high-severity vulnerabilities: a use-after-free in the low-level API affecting all versions, and an out-of-bounds read/write in the ARM Neon palette expansion affecting versions 1.6.36 through 1.6.55.

Users should either upgrade to libpng 1.6.56 or apply the fixes described below.

=== CVE-2026-33416 ===

Use-after-free via pointer aliasing in pngsettRNS and pngsetPLTE

Security advisory: https://github.com/pnggroup/libpng/security/advisories/GHSA-m4pc-p4q3-4c7j

Fixes: https://github.com/pnggroup/libpng/commit/23019269764e35ed8458e517f1897bd3c54820eb https://github.com/pnggroup/libpng/commit/7ea9eea884a2328cc7fdcb3c0c00246a50d90667

CVSS 3.1: 7.5 (High) - CVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:U/C:H/I:H/A:H CWE: CWE-416 (Use-After-Free) Affected: all versions through 1.6.55 Fixed: libpng 1.6.56

pngsettRNS and pngsetPLTE each alias a heap-allocated buffer between pngstruct and pnginfo, sharing a single allocation across two structs with independent lifetimes. Calling pngfreedata (or a second call to pngsettRNS / pngsetPLTE) 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.

Impact: - Read-after-free: freed heap memory read via dangling pointer in row-transform functions; may leak sensitive heap contents - Write-after-free: the PNGREADINVERTALPHA complement loop (transalpha) and bit-shift transforms (palette) write attacker-influenced values to freed heap memory - Arbitrary code execution has been demonstrated in proof-of-concept exploits on allocators with deterministic reuse (e.g. glibc tcache)

The crafted PNG files that trigger this vulnerability are valid per the PNG specification and pass all PNG validators.

Credits: - Halil Oktay (discovery and fix) - Ryo Shimada (independent discovery and exploitability demonstration) - Cosmin Truta (follow-up fix)

=== CVE-2026-33636 ===

Out-of-bounds read/write in the palette expansion on ARM Neon

Security advisory: https://github.com/pnggroup/libpng/security/advisories/GHSA-wjr5-c57x-95m2

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

CVSS 3.1: 7.6 (High) - CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:L/I:L/A:H CWE: CWE-125 (Out-of-bounds Read), CWE-787 (Out-of-bounds Write) Affected: libpng 1.6.36 through 1.6.55 Fixed: libpng 1.6.56

The ARM/AArch64 Neon-optimized palette expansion functions process rows in fixed-size chunks (4 pixels for RGBA, 8 for RGB), working backward from the end of the row. The loop bound permits a final iteration when fewer than a full chunk of input pixels remain, causing reads before the start of the row buffer and writes of expanded pixel data to the same underflowed positions.

Impact: - Out-of-bounds read: may leak heap contents through decoded pixel output, since the palette is attacker-controlled - Out-of-bounds write: attacker-influenced palette data written at deterministic negative offsets from the row buffer (heap corruption) - Denial of service: reliable process crashes confirmed

Only ARM/AArch64 builds with Neon enabled are affected. Builds targeting Intel SSE2, PowerPC VSX, LoongArch LSX, or generic C code are NOT affected.

Workaround: build with CFLAGS set to "-DPNGARMNEONOPT=0".

Credits: - Taegu Ha (discovery and fix) - Cosmin Truta (follow-up fix)

=== References ===

- Release: https://github.com/pnggroup/libpng/releases/tag/v1.6.56 - libpng homepage: http://www.libpng.org/pub/png/libpng.html

--- Cosmin Truta libpng maintainer

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

Hello, everyone,

libpng 1.6.55 has been released to address a heap buffer overflow vulnerability in the low-level API. This release fixes one high-severity CVE affecting all versions of libpng.

CVE-2026-25646 (High): Heap buffer overflow in pngsetquantize when called with no histogram and a palette larger than twice the requested maximum number of colors.

The vulnerability exists in the color quantization code that reduces the number of colors in a palette. A logic error in the color distance table causes current palette indices to be stored where original indices are expected. After palette entries are swapped during color pruning, the index mismatch causes the pruning loop to fail to find valid candidates, the search bound grows past the end of a heap-allocated buffer, and out-of-bounds reads occur.

The images that trigger this vulnerability are valid per the PNG specification. The bug has existed since the initial version of pngsetquantize (then called pngsetdither).

Unlike the recent CVEs fixed in libpng 1.6.51, 1.6.52 and 1.6.54, which affected the simplified API, this vulnerability affects the low-level function pngsetquantize.

This can result in denial of service and potentially information disclosure or arbitrary code execution via heap corruption.

GitHub Security Advisory: - CVE-2026-25646: https://github.com/pnggroup/libpng/security/advisories/GHSA-g8hp-mq4h-rqm3

Fix: - https://github.com/pnggroup/libpng/commit/01d03b8453eb30ade759cd45c707e5a1c7277d88

Release: https://github.com/pnggroup/libpng/releases/tag/v1.6.55

Credit: Joshua Inscoe (reporter and fixer)

Users should upgrade to libpng 1.6.55 immediately.

--- Cosmin Truta libpng maintainer

Buffer Overflow vulnerability in libpng 1.6.43-1.6.46 allows a local attacker to cause a denial of service via pngcreatereadstruct() function.

Buffer Overflow vulnerability in libpng 1.6.43-1.6.46 allows a local attacker to cause a denial of service via the pngimage with AddressSanitizer (ASan), the program leaks memory in various locations, eventually leading to high memory usage and causing the program to become unresponsive

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.

Hello, everyone,

libpng 1.6.54 has been released, fixing two medium-severity heap buffer over-read vulnerabilities in the simplified API.

=== CVE-2026-22695 ===

Heap buffer over-read in pngimagereaddirectscaled (regression from CVE-2025-65018 fix)

Security advisory: https://github.com/pnggroup/libpng/security/advisories/GHSA-mmq5-27w3-rxpp Remediation commit: https://github.com/pnggroup/libpng/commit/e4f7ad4ea2

CVSS 3.1: 6.1 (Medium) - CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:U/C:L/I:N/A:H CWE: CWE-125 (Out-of-bounds Read) Affected: libpng 1.6.51 through 1.6.53 Fixed: libpng 1.6.54

This is a regression introduced by the fix for CVE-2025-65018. When processing interlaced 16-bit PNGs with 8-bit output format and non-minimal row stride, the pngimagereaddirectscaled() function used the caller's stride instead of the actual row width for memcpy, causing a heap buffer over-read.

Impact: - Information disclosure (low): over-read may expose adjacent heap data - Denial of service (high): negative stride causes deterministic crash

Applications using the default stride (rowstride = 0 or rowstride = PNGIMAGEROWSTRIDE(image)) are NOT affected.

Credit: Petr Simecek, Stanislav Fort and Pavel Kohout (discovery), Petr Simecek (fix)

=== CVE-2026-22801 ===

Integer truncation causing heap buffer over-read in pngimagewrite

Security advisory: https://github.com/pnggroup/libpng/security/advisories/GHSA-vgjq-8cw5-ggw8 Remediation commit: https://github.com/pnggroup/libpng/commit/cf155de014

CVSS 3.1: 6.1 (Medium) - CVSS:3.1/AV:L/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:H CWE: CWE-125 (Out-of-bounds Read), CWE-190 (Integer Overflow or Wraparound) Affected: libpng 1.6.26 through 1.6.53 Fixed: libpng 1.6.54

The simplified write API functions pngwriteimage16bit and pngwriteimage8bit cast ptrdifft rowbytes to pnguint16 before pointer arithmetic. This truncation causes heap buffer over-read when the caller provides a negative row stride (for bottom-up layouts) or a stride exceeding 65535 bytes.

Impact: - Information disclosure (low): over-read may expose heap data in output - Denial of service (high): infinite loop or crash from reading unmapped memory

Applications using default stride with images narrower than 65535 bytes per row and top-down layout are NOT affected.

Credit: Cosmin Truta (discovery and fix)

=== References ===

- GitHub Issue (CVE-2026-22695): https://github.com/pnggroup/libpng/issues/778 - libpng homepage: http://www.libpng.org/pub/png/libpng.html

--- Cosmin Truta libpng maintainer

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.

Greg

On 2025-12-03 13:33, Cosmin Truta wrote: [Cc-ing Greg Roelofs, who owns and maintains libpng.org [1]]

On Wed, Dec 3, 2025 at 11:09 PM Alan Coopersmith <alan.coopersmith () oracle com> wrote: Does this bug (and the recent bugs fixed in 1.6.51) not affect the older> branches of libpng, or is the statement that "libpng 1.2.x continues to get security fixes, as has 1.0.x for well over a decade" on https://libpng.org/pub/png/libpng.html no longer correct? The good news is this: neither this bug nor the ones in the previous v1.6.51 release affect those ancient libpng releases. What these bugs DO affect is a thing called "the simplified libpng API", which was added in libpng-1.6.0.

The bad news is this: https://libpng.org/pub/png/libpng.html I have seen that page a thousand times, and... yet... OOPSIE!! Is the statement on https://libpng.sourceforge.io/index.html that the older branches "ARE NO LONGER UPDATED" and were frozen in 2017 the correct one now?

Yes, that is correct.

Sincerely, Cosmin

Links: ------ [1] http://libpng.org

[Cc-ing Greg Roelofs, who owns and maintains libpng.org]

On Wed, Dec 3, 2025 at 11:09 PM Alan Coopersmith < alan.coopersmith () oracle com> wrote: Does this bug (and the recent bugs fixed in 1.6.51) not affect the older branches of libpng, or is the statement that "libpng 1.2.x continues to get security fixes, as has 1.0.x for well over a decade" on https://libpng.org/pub/png/libpng.html no longer correct? The good news is this: neither this bug nor the ones in the previous v1.6.51 release affect those ancient libpng releases. What these bugs DO affect is a thing called "the simplified libpng API", which was added in libpng-1.6.0.

The bad news is this: https://libpng.org/pub/png/libpng.html I have seen that page a thousand times, and... yet... OOPSIE!! Is the statement on https://libpng.sourceforge.io/index.html that the older branches "ARE NO LONGER UPDATED" and were frozen in 2017 the correct one now?

Yes, that is correct.

Sincerely, Cosmin

On 12/3/25 12:51, Cosmin Truta wrote: Hello, everyone,

libpng 1.6.52 has been released to address an out-of-bounds read vulnerability in the simplified API. This release fixes one high-severity CVE affecting libpng 1.6.0 through 1.6.51. Does this bug (and the recent bugs fixed in 1.6.51) not affect the older branches of libpng, or is the statement that "libpng 1.2.x continues to get security fixes, as has 1.0.x for well over a decade" on https://libpng.org/pub/png/libpng.html no longer correct?

Is the statement on https://libpng.sourceforge.io/index.html that the older branches "ARE NO LONGER UPDATED" and were frozen in 2017 the correct one now?

-- -Alan Coopersmith- alan.coopersmith () oracle com Oracle Solaris Engineering - https://blogs.oracle.com/solaris

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.

Hello, everyone,

libpng 1.6.52 has been released to address an out-of-bounds read vulnerability in the simplified API. This release fixes one high-severity CVE affecting libpng 1.6.0 through 1.6.51.

CVE-2025-66293 (CVSS 7.1, High): Out-of-bounds read in pngimagereadcomposite when processing palette PNG images with partial transparency and gamma correction.

Note: Unlike typical image parsing vulnerabilities, this bug is triggered by valid PNG files that conform to the PNG specification. Any palette image with a tRNS chunk containing partial alpha values (1–254) and a gAMA chunk will trigger the vulnerability when processed through the simplified API with an output format without alpha and no explicit background color. The bug is in libpng's internal flag synchronization, not in the image data.

A flag synchronization bug causes the compositing code to assume linear premultiplied data when the data is actually sRGB, resulting in reads up to 1012 bytes past the pngsRGBbase array. This can result in information disclosure and/or denial of service.

To the best of my knowledge, web browsers use the low-level libpng API rather than the simplified API, and are not affected by this vulnerability.

This is distinct from CVE-2025-64720 (fixed in 1.6.51), which also involved pngsRGBbase but occurred in a different code path and required a maliciously crafted PNG file to trigger.

GitHub Security Advisory: - CVE-2025-66293: https://github.com/pnggroup/libpng/security/advisories/GHSA-9mpm-9pxh-mg4f

Fixes: - https://github.com/pnggroup/libpng/commit/788a624d7387a758ffd5c7ab010f1870dea753a1 - https://github.com/pnggroup/libpng/commit/a05a48b756de63e3234ea6b3b938b8f5f862484a

Release: https://github.com/pnggroup/libpng/releases/tag/v1.6.52

Credit: flyfish101

Users should upgrade to libpng 1.6.52 immediately.

--- Cosmin Truta libpng maintainer

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

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, a heap buffer over-read vulnerability exists in libpng's pngwriteimage8bit function when processing 8-bit images through the simplified write API with convertto8bit enabled. The vulnerability affects 8-bit grayscale+alpha, RGB/RGBA, and images with incomplete row data. A conditional guard incorrectly allows 8-bit input to enter code expecting 16-bit input, causing reads up to 2 bytes beyond allocated buffer boundaries. 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 has been updated to version 1.6.51, which contains fixes for security vulnerabilities including CVE-2025-65018 and CVE-2025-64720.