That Innocent PNG Image Could Be Quietly Raiding Your App's Memory — Millions of Programs at Risk

Every time your browser, photo editor, or mobile app opens a PNG image, it trusts a 25-year-old piece of software to handle it safely — and right now, that trust has a dangerous crack in it.

What's happening

A high-severity vulnerability has been discovered in libpng, the foundational open-source library that sits quietly inside an enormous slice of the software world. We're talking about your web browser, your messaging apps, your image editing tools, game engines, medical imaging software, and thousands of web servers — virtually anything that reads or displays PNG files has libpng somewhere in its DNA. The flaw, tracked as CVE-2025-64720, carries a CVSS score of 7.1 out of 10, placing it firmly in the HIGH severity category. It has been present in every version of libpng from 1.6.0 all the way through 1.6.50 — a range that covers roughly a decade of releases and an almost uncountable number of deployed applications worldwide. The fix landed in version 1.6.51, but the race to patch is just beginning.

How the attack works

Imagine your application is a careful librarian who stores books — some of which contain sensitive documents — on a very long shelf. When a visitor hands the librarian a PNG image to process, the librarian follows a strict rulebook to handle it safely. This vulnerability is like slipping the librarian a specially crafted image that exploits a subtle mistake in the rulebook: when the image uses a color palette combined with a specific transparency optimization feature, the rulebook's math goes wrong. The librarian, following the flawed instructions faithfully, reaches past the end of the designated shelf and starts reading books that were never meant to be seen by visitors.

In practical terms, an attacker who can get a target application to open a malicious PNG file — through a malicious email attachment, a booby-trapped website image, or an uploaded file on a platform you run — can potentially cause the software to read memory it shouldn't have access to. That leaked memory could contain session tokens, passwords, encryption keys, or fragments of other users' private data, depending on what the application happens to have loaded at the time. While crashing the application outright is also possible, the more alarming scenario is the silent kind: data leaking without any visible error, with no one the wiser.

The technical reality

The root cause is an out-of-bounds read in the function png_image_read_composite, triggered when libpng processes palette-type PNG images with the PNG_FLAG_OPTIMIZE_ALPHA flag enabled. The bug originates one step earlier, in png_init_read_transformations, where the background compositing logic is incorrectly applied during the premultiplication phase of alpha processing. This violates a core invariant of libpng's simplified API: that every color component value must satisfy component ≤ alpha × 257. When that invariant breaks, the subsequent compositing arithmetic produces an index that walks outside the allocated palette buffer, resulting in a classic memory corruption / out-of-bounds read condition. Researchers should note this is specifically reachable through the simplified API path, meaning any application using png_image_begin_read_from_* style calls — a very common modern usage pattern — is in scope.

Who is at risk

If you develop software that processes user-supplied PNG images, you need to treat this as urgent. Any application built against libpng versions 1.6.0 through 1.6.50 is vulnerable, particularly if it handles palette-based PNGs and uses the simplified API or alpha optimization flags. This includes web applications that accept image uploads, content management systems, graphics tools, game servers, and embedded systems processing imagery. End users are exposed indirectly — if the apps and services you use daily haven't patched their dependencies, a malicious image served to you could trigger the flaw inside their infrastructure. No active exploitation has been confirmed in the wild yet, but the window between disclosure and weaponization is shrinking every year.

What you should do right now

1. Update libpng to version 1.6.51 immediately. If you maintain any application with libpng as a dependency, pull the patched release from the official libpng repository or your package manager right now. Run libpng-config --version or check your package manifest to confirm you're no longer on anything between 1.6.0 and 1.6.50.

2. Audit your dependency tree for bundled libpng copies. Many frameworks and applications ship their own statically linked copy of libpng rather than using the system version — meaning a system-level update won't protect you. Check vendored dependencies, Docker base images, and any third-party SDKs your project uses. Tools like Syft or Trivy can scan container images for exactly this kind of embedded library.

3. Restrict untrusted image uploads at the perimeter as a temporary measure. If you cannot patch immediately, add validation layers that reject palette-type PNGs or strip metadata at ingestion using a patched intermediary tool. This is a stopgap, not a fix — but it reduces your attack surface while the update pipeline catches up.