CVE-2026-33416: LIBPNG Use-After-Free Vulnerability

CVE-2026-33416 Overview

A use-after-free vulnerability has been identified in libpng, the reference library for reading, creating, and manipulating PNG (Portable Network Graphics) raster image files. The vulnerability exists in versions 1.2.1 through 1.6.55 and stems from improper memory management in the png_set_tRNS and png_set_PLTE functions, which alias heap-allocated buffers between png_struct and png_info structures that have independent lifetimes.

Critical Impact

Attackers can exploit this use-after-free condition to potentially execute arbitrary code or cause denial of service by crafting malicious PNG files that trigger memory corruption through dangling pointer dereferences.

Affected Products

• libpng versions 1.2.1 through 1.6.55
• Applications using affected libpng versions for PNG image processing
• All prior release lines of libpng that include the vulnerable png_set_tRNS and png_set_PLTE functions

Discovery Timeline

• 2026-03-26 - CVE CVE-2026-33416 published to NVD
• 2026-03-26 - Last updated in NVD database

Technical Details for CVE-2026-33416

Vulnerability Analysis

This vulnerability is classified as CWE-416 (Use After Free) and affects the core transparency and palette handling functions in libpng. The issue arises because png_set_tRNS and png_set_PLTE each create an alias between a heap-allocated buffer shared by both png_struct and png_info structures. These structures have independent memory management lifetimes, creating a dangerous scenario where freeing memory through one structure leaves the other with a dangling pointer.

The trans_alpha aliasing issue has been present in the codebase since at least libpng 1.0, while the palette aliasing was introduced in version 1.2.1. Both code paths are susceptible to exploitation when processing malformed or specially crafted PNG files.

Root Cause

The root cause lies in the buffer sharing design between png_struct and png_info. Specifically:

1. png_set_tRNS sets png_ptr->trans_alpha = info_ptr->trans_alpha, creating a shared reference to a 256-byte buffer
2. png_set_PLTE sets info_ptr->palette = png_ptr->palette, creating a shared reference to a 768-byte buffer

When png_free_data is called with PNG_FREE_TRNS or PNG_FREE_PLTE, it frees the buffer through info_ptr while the corresponding pointer in png_ptr remains dangling. Subsequent row-transform functions then dereference and potentially write to the freed memory. Additionally, a second call to either png_set_tRNS or png_set_PLTE triggers the same behavior because both functions internally call png_free_data before reallocating the info_ptr buffer.

Attack Vector

The attack vector is network-based, requiring user interaction to open a malicious PNG file. An attacker can craft a PNG image that triggers specific sequences of png_set_tRNS or png_set_PLTE calls followed by operations that access the freed memory. This could occur through:

• Web browsers rendering malicious PNG images
• Image processing applications opening attacker-supplied files
• Document viewers parsing embedded PNG content
• Any application using the vulnerable libpng functions for PNG manipulation

The following patches demonstrate the fix applied to resolve the use-after-free condition:

 
#if defined(PNG_tRNS_SUPPORTED) || \
    defined(PNG_READ_EXPAND_SUPPORTED) || defined(PNG_READ_BACKGROUND_SUPPORTED)
-   if ((png_ptr->free_me & PNG_FREE_TRNS) != 0)
-   {
-      png_free(png_ptr, png_ptr->trans_alpha);
-      png_ptr->trans_alpha = NULL;
-   }
-   png_ptr->free_me &= ~PNG_FREE_TRNS;
+   /* png_ptr->trans_alpha is always independently allocated (not aliased
+    * with info_ptr->trans_alpha), so free it unconditionally.
+    */
+   png_free(png_ptr, png_ptr->trans_alpha);
+   png_ptr->trans_alpha = NULL;
#endif

   inflateEnd(&png_ptr->zstream);

Source: GitHub Commit Update 23019269764e

The fix for the palette aliasing creates an independent copy rather than sharing the pointer:

   }
   if (png_ptr->palette == NULL)
   {
-      png_ptr->palette = palette;
+      /* Allocate an owned copy rather than aliasing the caller's pointer,
+       * so that png_read_destroy can free png_ptr->palette unconditionally.
+       */
+      png_ptr->palette = png_voidcast(png_colorp, png_calloc(png_ptr,
+          PNG_MAX_PALETTE_LENGTH * (sizeof (png_color))));
+      memcpy(png_ptr->palette, palette, (unsigned int)num_palette *
+          (sizeof (png_color)));
   }
   png_ptr->num_palette = (png_uint_16)num_palette;
 

Source: GitHub Commit Update 7ea9eea884a

Detection Methods for CVE-2026-33416

Indicators of Compromise

• Unexpected application crashes when processing PNG images, particularly those with transparency or palette data
• Memory corruption errors or segmentation faults in libpng-dependent applications
• Anomalous memory access patterns in processes handling PNG files
• Core dumps indicating use-after-free conditions in png_read_destroy or related functions

Detection Strategies

• Monitor for crashes in applications using libpng with stack traces involving png_set_tRNS, png_set_PLTE, or png_free_data functions
• Implement memory sanitizer tools (ASan, MSan) during application testing to detect use-after-free conditions
• Use static analysis tools to identify applications linked against vulnerable libpng versions (1.2.1 through 1.6.55)
• Deploy endpoint detection rules for anomalous memory behavior in image processing workflows

Monitoring Recommendations

• Inventory all applications and dependencies using libpng and verify version numbers
• Enable verbose logging for image processing applications to capture PNG parsing failures
• Configure endpoint protection to alert on memory corruption patterns in graphics rendering processes
• Monitor software composition analysis tools for vulnerable libpng dependencies in your codebase

How to Mitigate CVE-2026-33416

Immediate Actions Required

• Upgrade libpng to version 1.6.56 or later, which contains the fix for this vulnerability
• Audit all applications and dependencies that may bundle or statically link libpng
• Consider temporarily disabling PNG transparency or palette features in critical applications if immediate patching is not possible
• Implement input validation to restrict PNG processing to trusted sources until patches are applied

Patch Information

The vulnerability has been fixed in libpng version 1.6.56. The fix ensures that png_ptr->trans_alpha and png_ptr->palette are always independently allocated rather than aliased with info_ptr buffers. This prevents the dangling pointer condition by ensuring each structure manages its own memory independently.

Multiple commits address this issue:

• GitHub Commit 23019269764e - Resolves use-after-free on png_ptr->trans_alpha
• GitHub Commit 7ea9eea884a - Resolves use-after-free on png_ptr->palette
• GitHub Commit a3a21443ed12 - Initializes tail bytes in trans_alpha buffers

For complete details, see the GitHub Security Advisory GHSA-m4pc-p4q3-4c7j and Pull Request #824.

Workarounds

• Restrict PNG file processing to trusted sources only until patching is complete
• Implement sandboxing or process isolation for applications that process untrusted PNG files
• Use application-level controls to limit or disable PNG transparency and palette features if business requirements permit
• Deploy runtime memory protection mechanisms (ASLR, stack canaries) to increase exploitation difficulty

# Verify libpng version and update on Debian/Ubuntu systems
apt-cache policy libpng16-16
apt-get update && apt-get upgrade libpng16-16

# For systems using source builds, verify and upgrade
pkg-config --modversion libpng
# Download and build libpng 1.6.56 or later from official sources