CVE-2026-34757

What it actually does

This is a use-after-free flaw in libpng versions 1.0.9 through versions before 1.6.57. If application code obtains an internal chunk pointer using png_get_PLTE, png_get_tRNS, or png_get_hIST and then passes that same pointer back to the matching setter on the same png_struct/png_info pair, libpng frees the internal buffer before copying from the supplied pointer. Because the supplied pointer now references freed heap memory, libpng may copy stale data or unrelated heap contents into replacement PNG chunk metadata. The main technical impacts are silent metadata corruption and limited disclosure of heap contents within the process. Availability impact is not the primary concern, though hardened runtimes or sanitizers may terminate the process when the invalid memory access is detected.

Why it matters to the business

The practical risk is highest for software that programmatically reads and rewrites PNG metadata using libpng APIs, such as image-processing tools, asset pipelines, document converters, media services, graphics applications, and downstream Linux distributions that package libpng. Exploitation is not currently known to be widespread, EPSS is very low and flat, and the issue is not in CISA KEV; however, libpng is broadly embedded, so vulnerable code paths may exist indirectly in many applications. Consequences may include corrupted image metadata, leakage of small amounts of process memory into generated PNG structures, failed integrity checks, application instability under memory-safety tooling, and potential exposure of sensitive in-process data if an attacker can cause the affected API pattern to run on attacker-influenced images or metadata.

How an attack unfolds

An attacker first needs access to a program or workflow that uses vulnerable libpng versions and follows the unsafe get-then-set pattern with PLTE, tRNS, or hIST chunk data on the same png_struct/png_info pair. The attacker then supplies or influences PNG content or metadata that causes the application to parse the relevant chunks and later rewrite them through the corresponding setter. During that rewrite, libpng frees the internal chunk buffer, then reads from the caller-supplied pointer that still references the freed region. Depending on heap state, the replacement chunk may receive stale metadata or bytes from a later heap allocation. The attacker’s ability to control or extract useful data depends heavily on the surrounding application: a batch converter may simply emit corrupted PNG metadata, while a service that returns processed images could inadvertently include limited process heap contents in output PNG chunk structures. There is no public indication of active exploitation, named threat actor use, or ransomware use for this issue.

How to fix it

Upgrade libpng to version 1.6.57 or later wherever it is directly used or bundled. For Linux distributions such as Debian, install the vendor-provided security update for the libpng package rather than manually replacing shared libraries. Rebuild statically linked applications, containers, appliances, and language bindings that vendor or embed libpng, because updating the system package alone will not fix private copies. Where immediate upgrade is not possible, review application code for the unsafe pattern of passing pointers returned by png_get_PLTE, png_get_tRNS, or png_get_hIST directly back into png_set_PLTE, png_set_tRNS, or png_set_hIST on the same png_struct/png_info pair. Mitigate by copying the returned data into an independent application-owned buffer before calling the setter, or by avoiding unnecessary get-then-set operations. Treat PNG-processing pipelines that accept untrusted files and return rewritten PNGs as higher priority for patching.

How to confirm the fix worked

Confirm that all runtime and build-time libpng instances report version 1.6.57 or later, including shared libraries, statically linked binaries, containers, vendor directories, and application bundles. Use package manager inventory, software composition analysis, container image scanning, and binary inspection to find libpng versions before 1.6.57. For source validation, search for uses of png_get_PLTE, png_get_tRNS, and png_get_hIST followed by matching png_set_* calls using the same png_struct/png_info pair and returned pointer. For behavioral validation, run PNG metadata-processing tests under AddressSanitizer, Valgrind, or equivalent memory-safety tooling and confirm there are no heap-use-after-free findings in png_set_PLTE, png_set_tRNS, or png_set_hIST. For fixed builds, rerun representative PNG read/rewrite workflows and compare output metadata integrity against expected values.

Typical attack path

1. Identify an application, service, tool, or package that links against libpng 1.0.9 through a version before 1.6.57.
2. Determine whether the application uses png_get_PLTE, png_get_tRNS, or png_get_hIST and later passes the returned pointer to the matching png_set_* function on the same png_struct/png_info pair.
3. Provide or influence a PNG file or metadata workflow that exercises the affected chunk-handling path.
4. Trigger the application to parse and rewrite the relevant PNG chunks.
5. Cause libpng to free the internal buffer and then copy from the now-dangling pointer.
6. Observe the result, such as corrupted PLTE/tRNS/hIST metadata, sanitizer-detected heap-use-after-free, application failure, or limited disclosure of heap data in generated PNG output.

How to detect it

There are no unique network indicators for exploitation because this is a library memory-lifetime flaw triggered inside applications that use specific libpng APIs. To assess possible prior exploitation, review logs from image-processing services, batch conversion jobs, graphics applications, media upload pipelines, document conversion systems, and crash collectors for heap-use-after-free, invalid read, or memory corruption reports involving png_set_PLTE, png_set_tRNS, or png_set_hIST. Examine sanitizer, Valgrind, core dump, EDR, and application exception telemetry for crashes or aborts in libpng during PNG metadata rewrite operations. If processed PNG outputs are retained, inspect suspicious outputs for unexpected or corrupted PLTE, tRNS, or hIST chunks, especially files generated after processing untrusted PNG input. In source and build telemetry, look for the unsafe API sequence where a pointer returned by png_get_PLTE, png_get_tRNS, or png_get_hIST is reused as input to the corresponding setter. Because exploitation depends strongly on application logic and heap layout, absence of these artifacts does not prove non-exploitation; it only reduces evidence of known observable failure modes.

• heap-use-after-free
• AddressSanitizer: heap-use-after-free
• ERROR: AddressSanitizer
• Invalid read
• Use of uninitialised value
• png_set_PLTE
• png_set_tRNS
• png_set_hIST
• png_get_PLTE
• png_get_tRNS
• png_get_hIST
• libpng error
• libpng warning
• PLTE
• tRNS
• hIST
• libpng.so
• libpng16.so

What your security team should do

• Inventory all direct, transitive, bundled, and statically linked uses of libpng across applications, containers, appliances, build images, and third-party packages.
• Prioritize upgrades for systems that process untrusted PNG files, perform image conversion, rewrite PNG metadata, or return generated PNG files to users.
• Upgrade libpng to 1.6.57 or later, or apply the relevant operating-system vendor security update for packaged deployments.
• Ask application teams to review code for unsafe get-then-set usage involving png_get_PLTE/png_set_PLTE, png_get_tRNS/png_set_tRNS, and png_get_hIST/png_set_hIST.
• Rebuild and redeploy applications that statically link or vendor libpng after the patched dependency is available.
• Add regression tests or sanitizer-based CI jobs for PNG metadata read/write paths to catch similar memory lifetime errors.
• Monitor crash, sanitizer, and image-processing logs for heap-use-after-free signatures involving libpng setters, especially in services handling untrusted PNG input.
• Do not treat this as an emergency internet-scale remote-code-execution issue based on current intelligence, but include it in normal dependency remediation because libpng is widely reused.