CVE-2026-33416
Use-After-Free in libpng's png_set_tRNS and png_set_PLTE
Publication date: 2026-03-26
Last updated on: 2026-04-02
Assigner: GitHub, Inc.
Description
Description
CVSS Scores
EPSS Scores
| Probability: | |
| Percentile: |
Meta Information
Affected Vendors & Products
| Vendor | Product | Version / Range |
|---|---|---|
| libpng | libpng | From 1.2.1 (inc) to 1.6.56 (exc) |
Helpful Resources
Exploitability
| CWE ID | Description |
|---|---|
| CWE-416 | The product reuses or references memory after it has been freed. At some point afterward, the memory may be allocated again and saved in another pointer, while the original pointer references a location somewhere within the new allocation. Any operations using the original pointer are no longer valid because the memory "belongs" to the code that operates on the new pointer. |
Attack-Flow Graph
AI Powered Q&A
Can you explain this vulnerability to me?
CVE-2026-33416 is a use-after-free vulnerability in the libpng library versions 1.2.1 through 1.6.55. The issue arises because two internal structures, png_struct and png_info, share heap-allocated buffers for palette and transparency data, but manage their lifetimes independently. Specifically, functions png_set_tRNS and png_set_PLTE alias pointers between these structures, causing dangling pointers when the buffers are freed through one structure but still referenced by the other.
When the shared buffers are freed via png_free_data or by repeated calls to these functions, the other structure's pointer remains dangling. Subsequent operations then dereference or write to this freed memory, leading to undefined behavior and potential security risks such as heap corruption or arbitrary code execution.
The vulnerability was fixed by decoupling the lifetimes of these buffers: both png_struct and png_info now maintain independently allocated copies of the palette and transparency buffers, preventing dangling pointers and unsafe memory accesses.
How can this vulnerability impact me? :
This vulnerability can have serious impacts including heap corruption, information disclosure, and arbitrary code execution. Because the freed memory can be read or written after being freed, attackers can manipulate heap memory to overwrite security-critical data or function pointers.
Exploitation is feasible especially on systems without modern memory protections like PIE or ASLR, such as embedded systems or legacy servers. Attackers can craft malicious PNG files that trigger the use-after-free condition, potentially leading to control-flow hijacking and remote code execution.
Applications that call png_free_data between png_read_info and png_read_update_info are particularly vulnerable, a pattern common in memory-constrained embedded devices and server-side image processing pipelines.
What immediate steps should I take to mitigate this vulnerability?
To mitigate the CVE-2026-33416 vulnerability in libpng, you should upgrade libpng to version 1.6.56 or later, where the issue is fixed by decoupling the lifetimes of the palette and transparency buffers between the internal structures. This prevents use-after-free conditions by ensuring independent allocation and freeing of these buffers.
Specifically, the fix involves:
- Upgrading libpng to version 1.6.56 or newer.
- Avoiding use of vulnerable libpng versions (1.2.1 through 1.6.55) in your applications.
- If you maintain software that calls libpng, ensure it does not call png_free_data() between png_read_info() and png_read_update_info(), as this usage pattern is vulnerable.
- Apply patches or updates provided by libpng maintainers that implement independent allocation and freeing of palette and transparency buffers.
These steps will prevent dangling pointers and use-after-free errors that could lead to heap corruption or arbitrary code execution.
How does this vulnerability affect compliance with common standards and regulations (like GDPR, HIPAA)?:
CVE-2026-33416 is a high-severity use-after-free vulnerability in the libpng library that can lead to arbitrary code execution through controlled heap corruption. This vulnerability allows attackers to potentially execute malicious code by exploiting dangling pointers in memory management related to PNG image processing.
While the CVE description and resources do not explicitly mention compliance with standards such as GDPR or HIPAA, the vulnerability's potential to cause arbitrary code execution and memory corruption could lead to unauthorized access, data breaches, or system compromise. Such security incidents may result in violations of data protection regulations like GDPR or HIPAA, which require organizations to protect personal and sensitive data against unauthorized access and ensure system integrity.
Therefore, organizations using vulnerable versions of libpng in their software stack should consider this vulnerability a significant risk to their compliance posture, as exploitation could lead to breaches of confidentiality, integrity, and availability of protected data.
How can this vulnerability be detected on my network or system? Can you suggest some commands?
This vulnerability is a use-after-free issue in the libpng library versions 1.2.1 through 1.6.55, specifically affecting the handling of palette and transparency buffers in PNG image processing. Detection on a network or system involves identifying usage of vulnerable libpng versions or scanning PNG files that might trigger the vulnerability.
To detect if your system is vulnerable, you can check the installed libpng version using commands like:
- On Linux, run: `ldconfig -p | grep libpng` or `dpkg -l | grep libpng` (Debian/Ubuntu) or `rpm -qa | grep libpng` (RedHat/CentOS) to find installed libpng versions.
- Alternatively, check the version of libpng linked to your applications by running: `strings /path/to/application | grep libpng` or `ldd /path/to/application | grep libpng`.
To detect exploitation attempts or suspicious PNG files on your network, you can use file inspection tools or network monitoring to identify PNG files with suspicious tRNS or PLTE chunks, as these are involved in the vulnerability.
No specific detection commands or signatures are provided in the available resources. However, monitoring application logs for crashes or memory errors related to libpng during PNG processing may help identify exploitation attempts.