libpng CVE-2026-46675

Exploitation requires the target application to use libpng's sequential reader and to call png_read_end after png_read_info WITHOUT first reading the image rows (or calling png_start_read_image) - the maintainer notes this call sequence is rare in practice. The malicious input must be a PNG containing a zTXt, iTXt, or iCCP chunk that causes libpng to abandon zlib decompression early (invalid zlib window size, decompressed data exceeding limits, or an ICC profile failing validation). For the heap variant (zTXt/iTXt) a larger tEXt/pCAL chunk before IDAT must reallocate the read buffer to realize the use-after-free; the iCCP variant is a stack use-after-return. The crash outcome further depends on the freed memory being unmapped at read time. Limiting factors: no authentication or user interaction is required in CVSS terms, but the atypical application API usage and the memory-state dependency substantially constrain real-world reachability, and impact is confined to a crash (denial of service) with no data disclosure or corruption. Affected libpng 1.6.0 through 1.6.58; fixed in 1.6.59.

The vendor-supplied CVSS 3.1 vector (AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:H, 5.9 Medium) is internally consistent with the technical description and I concur with it. The vulnerability is network-reachable (a crafted PNG is delivered as data) and needs no authentication or user interaction in the CVSS sense, but AC:H is well-justified: exploitation depends on a specific and, per the maintainer, rare application call sequence (png_read_end invoked after png_read_info without reading image rows) plus precise heap grooming so that the freed buffer is reallocated or unmapped. Impact is availability-only (A:H, a crash) - the maintainer explicitly states the dangling pointer is only read into a discarded scratch buffer, so there is no confidentiality or integrity impact (C:N/I:N is correct). Exploitation status: no public exploit identified at time of analysis - there is no CISA KEV listing, no EPSS score, and no POC in the provided data; the two credited reports (Ze Sheng/O2Lab/AISLE and @JasonHonKL) are vulnerability discoveries, not weaponized exploits. This is best characterized as a real but low-priority defect: although libpng is ubiquitous, the flaw is not remote code execution, yields at most a crash, and only in applications using an atypical API sequence, so it is a genuine medium-severity hardening fix rather than an urgent threat. No key signals are conflicting; the main missing signals (EPSS, KEV, POC) are simply absent, which is consistent with a hard-to-reach availability bug.

An attacker supplies a crafted PNG whose zTXt, iTXt, or iCCP chunk aborts zlib decompression early (e.g., an invalid zlib window size or an ICC profile that fails validation), leaving a stale zlib input pointer. If the victim application then calls png_read_end after png_read_info without having read the image rows, libpng resumes decompression from the freed/expired pointer, causing a heap use-after-free (or stack use-after-return for iCCP) that can crash the process when the memory is no longer mapped. No public exploit code is identified, and the vulnerable call pattern is uncommon, so practical impact is limited to denial of service.