CVE-2026-33416: 
NixOS vulnerability analysis and mitigation

CVE-2026-33416 is a use-after-free (UAF) vulnerability in libpng affecting versions 1.2.1 through 1.6.55, caused by heap buffer aliasing between png_struct and png_info in the png_set_tRNS and png_set_PLTE functions. Discovered independently by Halil Oktay (@Oblivionsage) and Ryo Shimada (@shimarda, University of Tsukuba / Powder Keg Technologies), it was publicly disclosed on March 25–26, 2026, with a fix released in libpng 1.6.56 (GitHub Advisory). The vulnerability has a CVSS v3.1 base score of 7.5 (High) (GitHub Advisory, Microsoft MSRC).

The root cause (CWE-416: Use After Free) lies in pointer aliasing introduced by png_set_tRNS and png_set_PLTE: png_set_tRNS sets png_ptr->trans_alpha = info_ptr->trans_alpha (sharing a 256-byte heap buffer), and png_set_PLTE sets info_ptr->palette = png_ptr->palette (sharing a 768-byte buffer). When png_free_data is called with PNG_FREE_TRNS or PNG_FREE_PLTE, the buffer is freed through info_ptr while png_ptr retains a dangling pointer. Subsequent row-transform functions such as png_do_expand_palette dereference — and in some paths write to — the freed memory (GitHub Advisory, libpng PR #824). The vulnerability is network-reachable (AV:N) but requires user interaction (e.g., opening a crafted PNG) and has high attack complexity, as exploitation depends on heap allocator behavior and application-specific code paths (GitHub Advisory).

Successful exploitation enables read-after-free (leaking sensitive heap contents) and write-after-free (heap corruption). For the trans_alpha variant, the PNG_READ_INVERT_ALPHA complement loop writes attacker-controlled values (via tRNS chunk entries) to freed memory; for the palette variant, bit-shift transforms perform read-modify-write on freed memory. On allocators with deterministic reuse (e.g., glibc tcache, default since glibc 2.26+), the freed buffer can be reclaimed by a subsequent allocation containing function pointers or security-critical data, enabling control-flow hijack and arbitrary code execution — demonstrated with a PoC RCE exploit in non-PIE environments (GitHub Advisory). In PIE/ASLR environments, exploitation requires an additional information leak or brute-forcing (practical on 32-bit systems).

A public proof-of-concept (PoC) C program is available in libpng PR #824, which reproduces the heap-use-after-free crash detectable via AddressSanitizer by calling png_free_data(p, i, PNG_FREE_TRNS, 0) followed by png_read_row(p, row, NULL) (libpng PR #824). An RCE PoC has also been demonstrated in non-PIE environments by the independent reporter Ryo Shimada (GitHub Advisory). The EPSS score is approximately 0.047% (low probability of near-term exploitation), and there is no evidence of in-the-wild exploitation or CISA KEV catalog listing as of the time of this report (Feedly). The crafted PNG payload is fully standards-compliant and cannot be distinguished from valid PNG files by upstream filters or WAFs (GitHub Advisory).

1. Craft a malicious PNG: Create a palette-based PNG file with a tRNS chunk containing attacker-controlled transparency values. The file is fully standards-compliant and passes all PNG validators.
2. Deliver the PNG: Serve the crafted PNG to a target application that processes PNG files from untrusted sources (e.g., a web server, image viewer, or embedded system using libpng 1.2.1–1.6.55).
3. Trigger the aliasing: The application calls png_read_info(), which internally invokes png_set_tRNS(), aliasing png_ptr->trans_alpha to info_ptr->trans_alpha (same heap buffer).
4. Free the buffer: The application (or libpng internally on a second call to png_set_tRNS) calls png_free_data(png_ptr, info_ptr, PNG_FREE_TRNS, 0), freeing the buffer through info_ptr while png_ptr->trans_alpha remains dangling.
5. Trigger the UAF: The application calls png_read_row(), which invokes png_do_expand_palette() or png_init_palette_transformations(), dereferencing the freed png_ptr->trans_alpha pointer — causing a heap-use-after-free.
6. Achieve heap corruption or RCE: If PNG_READ_INVERT_ALPHA is enabled, the complement loop writes attacker-controlled values (from the tRNS chunk) to the freed buffer. On glibc tcache allocators, if the freed 256-byte buffer is reclaimed by a struct containing function pointers, the attacker-written values can redirect control flow, achieving RCE in non-PIE environments (GitHub Advisory, libpng PR #824).

• Process: Application crashes (SIGABRT, SIGSEGV) in processes that parse PNG files, particularly in functions png_do_expand_palette, png_do_read_transformations, or png_read_row; AddressSanitizer reports of heap-use-after-free at pngrtran.c:4455 or similar offsets.
• Logs: Application error logs showing unexpected termination or memory corruption errors during PNG processing; crash dumps referencing libpng internal functions (png_free_data, png_set_tRNS, png_set_PLTE).
• Network: Inbound delivery of PNG files with tRNS or PLTE chunks to image-processing endpoints, especially from untrusted or external sources; anomalous PNG files that trigger repeated processing errors.
• File System: Presence of crafted PNG files with tRNS chunks containing non-standard transparency values (e.g., all entries set to specific byte patterns like 128, 64) in upload directories or temporary processing folders.

The primary remediation is to upgrade libpng to version 1.6.56 or later, which gives png_struct its own independently allocated copies of both trans_alpha and palette, decoupling their lifetimes from png_info (GitHub Advisory). Patches are available via four commits: 2301926 (trans_alpha fix), a3a2144 (trans_alpha defense-in-depth), 7ea9eea (palette fix), and c1b0318 (palette sync fix). Downstream distributions including Debian, Ubuntu, Red Hat, SUSE, Fedora, Amazon Linux, and Slackware have issued updated packages (Microsoft MSRC). As a workaround, applications should avoid calling png_free_data() with PNG_FREE_TRNS or PNG_FREE_PLTE between png_read_info() and png_read_update_info(), and avoid calling png_set_tRNS or png_set_PLTE a second time on the same read struct.

The vulnerability received broad coverage across Linux distribution security channels, with advisories issued by Debian, Ubuntu (USN-8251-1), Red Hat (multiple RHSAs), SUSE, Fedora, Amazon Linux, Slackware, Mageia, and openSUSE shortly after disclosure (Microsoft MSRC). Security news outlets including GBHackers, CyberSecurityNews, SecurityOnline, and CyberPress covered the vulnerability, highlighting its potential for RCE and sensitive data leakage (Feedly). The libpng maintainer Cosmin Truta publicly acknowledged both independent discoverers and noted that the aliasing issue had been flagged with a TODO comment in the codebase for years but never addressed (libpng PR #824). Huawei also issued security bulletins referencing this CVE for its device product lines (Feedly).