CVE-2026-3713: Heap Overflow in libpng pnm2png Contrib Tool

A newly disclosed vulnerability in the pnggroup libpng project—tracked as CVE-2026-3713—allows a specially crafted PNM image to trigger a heap-based buffer overflow in the library’s pnm2png utility, and a public proof-of-concept has already been published. This bug stems from an integer-wrap/size-calculation error in the contrib tool’s do_pnm2png routine, which can result in allocation of an undersized buffer followed by unbounded writes. The flaw affects libpng releases up to and including 1.6.55, the exploit is local-only, and as of publication there is no upstream fix merged into the mainline repository. (nvd.nist.gov) (github.com) (github.com)

Background / Overview​

libpng is the reference implementation and de facto standard for reading and writing PNG files. The project maintains a core library plus various example/demo and contrib utilities, historically including tools such as pnm2png (part of contrib/pngminus). While many security holes in libpng over the years have affected core APIs and widely-used library calls, this new issue lives in a contrib utility that is distributed with libpng source snapshots and sometimes packaged by distributions. That packaging detail—whether the vulnerable tool is present and enabled on a given system—determines real-world exposure.
CVE-2026-3713 was first publicly reported through a GitHub issue (pnggroup/libpng #794, opened Feb 18, 2026) that includes a detailed analysis and an AddressSanitizer-backed proof-of-concept demonstrating a heap-buffer-overflow triggered by crafted width/height values read from a PNM header. The NVD entry published March 8, 2026 summarizes the finding and notes that the exploit has been published and that the upstream project had been notified but had not yet provided a response or a fix at that time. (github.com) (nvd.nist.gov)

What the bug is (technical summary)​

• Component: contrib/pngminus/pnm2png.c, function do_pnm2png().
• Root cause: arithmetic/integer-wrap in row-size calculation and inconsistent use of the resulting value during allocation vs write, allowing allocation of a buffer smaller than the number of bytes written.
• Trigger: attacker-controlled width and height values parsed from the PNM file header; values can range across the full 32-bit unsigned range when read by the utility’s parsing routine.
• Consequence: heap-based buffer overflow when the code writes width * channels bytes into a buffer sized by the wrapped row_bytes value.
• Exploitability: local execution only (requires feeding a malicious PNM file to the vulnerable tool or invoking an application that calls the vulnerable code with attacker-controlled input). A functioning PoC and ASan trace demonstrating heap-buffer-overflow were published along with the GitHub issue. (github.com) (github.com)

The vulnerable control flow is straightforward: width/height are read into unsigned 32-bit variables; a check compares row_bytes against zero and attempts to ensure height row_bytes does not overflow the host’s size_t. But if the multiplication wraps—i.e., row_bytes is computed from width and channels such that the 32-bit integer overflows—the later guard can miss the condition and the code proceeds to allocate row_bytes bytes. The subsequent pixel-writing loop still uses the original width and channels to determine how many bytes to write per row, so if widthchannels exceeds the wrapped/undersized row_bytes value, writes overflow the heap allocation. In short: integer wrap -> undersized allocation -> unchecked writes -> heap overflow. (github.com)

Why this matters​

At first glance this looks like “only a contrib utility.” That reduces the attack surface compared to a flaw in libpng’s core API functions that are linked into countless GUI apps, server processes, and image-processing libraries. But there are three reasons this is still serious for defenders and packagers:

• Contrib tools are packaged by many distributions as part of libpng packages or separate libpng-tools packages; where installed, pnm2png is a local binary available to users and system scripts. Debian, Ubuntu and other distros historically packaged libpng tools as part of their libpng-tools or libpng packages. An installed pnm2png binary exposes the local-execution attack vector.
• Even if pnm2png is not installed system-wide, downstream projects or developers occasionally compile and bundle the contrib tools, or include the pnm2png code in other utilities; static linking or vendor bundling can bring the vulnerable code into unexpected software. That makes inventory and software composition analysis more important than a naive “this is a contrib tool, ignore it” reaction.
• The presence of a public PoC lowers the bar for misuse: security researchers can reproduce the issue to demonstrate impact, but attackers can also adapt PoC code for local privilege escalation, code execution, or post-exploit leverage on multi-user systems where a vulnerable tool runs with elevated or service-equivalent privileges. The NVD and GitHub notes explicitly state a PoC exists and the project had not yet responded at the time of those posts. (nvd.nist.gov)

For these reasons, operators who manage servers, shared workstations, build farms, CI runners, or developer laptops should treat this as actionable: search your systems for installed pnm2png binaries, audit packages that include libpng contrib tools, and check vendor/Distro advisories for timelines and vendor-patched package builds. Several vulnerability-tracking entities and scanning plugins have already added detection logic and warnings for this CVE.

---

Timeline and public disclosure​

• Feb 18, 2026: GitHub issue #794 opened by researcher “biniamf,” including a detailed technical write-up and ASan proof-of-concept demonstrating the heap-buffer-overflow in do_pnm2png(). (github.com)
• Mar 8, 2026: NVD publishes CVE-2026-3713 (record reflects a source of VulDB for the initial data) and notes the exploit has been published. NVD’s page states that the project was informed early through an issue report but had not yet responded at publication time. (nvd.nist.gov)
• Early March 2026: Additional vulnerability databases (VulDB, PT dbugs, OSV, Tenable plugin feeds) add entries; various downstream advisories and scanners list the issue as unpatched in upstream libpng through 1.6.55. (dbugs.ptsecurity.com)

Note: public timelines show the researcher responsibly disclosed a working PoC via GitHub issue and the vulnerability was escalated into the CVE/NVD ecosystem within a few weeks. The key outstanding item is an upstream patch; at time of writing the project had not merged a committed fix referenced in the issue thread. Stay prepared to install vendor-supplied or upstream package updates as soon as they are published.

---

Reproduction and proof-of-concept (high level)​

The published PoC repository contains a minimal PNM file designed to exercise the integer-wrap condition. The researcher explains how to build the libpng pnm2png utility with AddressSanitizer and how running the PoC file produces an AddressSanitizer heap-buffer-overflow trace pointing into do_pnm2png. The PoC demonstrates:

• Building an asan-instrumented pnm2png from libpng source.
• Running pnm2png with the crafted PNM file causes a heap-buffer-write just after allocation, with ASan reporting the overflow and stack trace into do_pnm2png.
• The footprint and steps are short and reliable on supported builds; the PoC includes the offending PNM blob and ASan reproduction commands. (github.com)

This is important because a PoC lowers the friction for both blue-team validation and for potential malicious adaptation. Defenders should prioritize detection and mitigation steps rather than assuming “local-only” means “low priority.”

---

Impact assessment: who and what is at risk​

• Local users and developers: On systems where pnm2png is installed and readable/executable by untrusted users, simply opening or processing a malicious PNM file with that tool can crash or corrupt memory. Where processes run with elevated privileges (e.g., build scripts run as service accounts, automated ingestion tools, or scheduled conversion jobs), an attacker could potentially escalate impact.
• CI/build servers and image-processing pipelines: These systems often process image files automatically. If any pipeline invokes pnm2png or links to an application that uses the vulnerable code path, a crafted input could break builds, cause crashes, or be leveraged for further action if the runtime privileges are sufficient.
• Vendor-bundled software: Applications that vendor libpng sources (including contrib tools) or statically link utility code could carry the vulnerable code even on platforms where the system libpng is patched. Static analysis and SBOM checks are necessary to discover such cases.
• Windows ecosystem: While pnm2png is a Unix-style utility, libpng is widely used on Windows via DLLs and bundled libraries. The precise risk on Windows depends on whether the pnm2png code path is compiled and exposed in a shipped binary. Windows-specific installables or developer toolchains that include libpng contrib utilities are an audit target.

Severity: multiple sources rate this as medium (CVSS values contributed by third parties vary; NVD had not assigned a final CVSS at the time of the NVD snapshot). The medium rating reflects two balancing facts: the exploit is local-only and the vulnerable code is in a contrib tool (reducing broad remote exposure), but the presence of a public PoC and the potential for local privilege abuse or pipeline disruption elevate operational risk. (nvd.nist.gov)

---

Mitigation and remediation (practical guidance)​

If you manage Linux, Windows, or mixed environments that build or ship libpng, take the following steps immediately.

• Inventory and detection
• Search for the pnm2png binary on endpoints and servers:
• Linux: which pnm2png || command -v pnm2png; dpkg -S pnm2png (Debian/Ubuntu); rpm -q --whatprovides pnm2png (RHEL/CentOS); pacman -Qs libpng-tools (Arch).
• Windows (MSYS2 / MSVC toolchains): scan for pngminus/pnm2png.EXE in developer toolchains and build output directories.
• Use your organization’s asset inventory or SBOM tools to find packages or products that include libpng versions <= 1.6.55 or that vendor libpng contrib tools.
• Temporary workarounds (quick, low-risk)
• Remove or restrict the pnm2png binary until a patch is available:
• Remove the executable (sudo rm /usr/bin/pnm2png) or move it to a quarantine location.
• Restrict execution with file permissions (chmod 700 /usr/bin/pnm2png) and ensure only trusted accounts retain execution rights.
• Block ingestion of untrusted PNM files in automated pipelines, or run image conversion code in isolated sandboxes/container runtimes with strict user separation and seccomp-like restrictions.
• If a vendor supplies applications that call pnm2png, contact the vendor or apply application-level hardening/whitelisting.
• Patch and update strategy
• Monitor official libpng releases, the pnggroup/libpng GitHub repository, and your Linux distribution vendors (Ubuntu, Debian, Red Hat, Alpine, etc.) for a fixed libpng package that addresses CVE-2026-3713.
• Apply vendor-supplied packages as soon as they are available. If vendor packages are delayed, consider backporting a local patch or removing the vulnerable utility from deployed images.
• For downstream product teams that statically link libpng or ship vendor-bundled libpng, rebuild and re-release with the fixed library once a patch is available.
• Detection and logging
• Add file-detection rules to your EDR/AV for the proof-of-concept file signatures or for suspicious PNM headers (extremely large numeric width/height entries).
• Monitor logs for unexpected pnm2png executions, crashes, or ASan-style diagnostics if you run instrumented builds on CI.
• Hardening and long-term fixes
• Prefer OS-packaged libpng builds rather than vendor-bundled or statically linked copies; packaged versions are easier to update and patch at scale.
• For build infrastructures, enable sanitizers (AddressSanitizer, UBSan) in CI for image-conversion tools and related utilities to catch issues before deployment.
• Update procurement and SBOM policies to track use of contrib/demo tools from upstream projects and treat such inclusions as potential risk vectors.
• Emergency triage if exploit suspected
• If an intrusion is suspected where pnm2png or a related tool crashed on a production box, isolate the host, collect memory and crash dumps, and preserve the PoC file for forensic work.
• Use process accounting (auditd/Windows event logs) to reconstruct the timeline of any suspicious pnm2png invocation.

---

Detection examples and admin commands​

• Check for the pnm2png executable (Linux):
• which pnm2png || command -v pnm2png
• dpkg -S $(which pnm2png) # Debian/Ubuntu (if installed)
• rpm -qf $(which pnm2png) # RHEL/Fedora/CentOS (if installed)
• Search for libpng versions in packages:
• dpkg -l | grep libpng
• rpm -qa | grep libpng
• On Windows (MSYS2 / developer tools) scan for pngminus/pnm2png:
• dir /s /b pnm2png.exe
• Use SBOM and artifact scanners (OSS dependency scanners) to list components that reference libpng <= 1.6.55 and flag them for review.

These commands are simple starting points—use centralized asset management wherever possible for fleet-wide queries and automated remediation.

---

Risk analysis and critical perspective​

Strengths of the discovery and disclosure process:

• The researcher provided a clear, minimal PoC and reproduced the issue under AddressSanitizer; that reduces ambiguity and accelerates vendor patching and vendor advisories.
• Public tracking via GitHub issue + NVD entry + OSV/VulDB publicity allows defenders and vendors to coordinate and prioritize packaging patches.

Operational risks and open questions:

• The main uncertainty is distribution packaging and vendor response. Because the vulnerable code sits in a contrib tool, many sysadmins might assume “not my problem” and fail to inventory or patch affected boxes. That complacency is risky: packaged tools and vendor-bundled static copies are a common source of surprise.
• The exploit is local-only, which lowers remote-exploitation concern. But local-only exploits are still a real threat in multi-user systems, build servers, shared hosting, and developer workstations—contexts where privilege boundaries are critical.
• The project’s initial non-response (as reported in NVD’s early snapshot) delayed a canonical upstream patch. This leaves packaging teams and vendors to decide whether to pull the contrib tool from distributed packages or to ship interim backports. The absence of a unified upstream patch increases inconsistent mitigation across distros and vendor products. (nvd.nist.gov)

Practical risk prioritization:

• High priority: systems that process untrusted image content automatically (CI, build farms, image ingestion services) and any servers where a compromised low-privilege account could escalate using the vulnerable tool.
• Medium priority: developer machines and shared workstations that might run pnm2png or include bundled libpng tooling.
• Lower priority: systems that do not have pnm2png installed and that do not vendor libpng contrib tools—but these systems still require SBOM-based verification.

---

Recommendations for packagers and vendor teams​

• Immediately audit packaging policies that include contrib/demo utilities by default. Consider splitting out contrib tools in separate subpackages (e.g., libpng-tools) and disable automatic installation in server or minimal images.
• For vendor teams that ship single-binary installers or embedded appliances, re-scan builds for any inclusion of contrib code and prepare rebuilds that remove or patch vulnerable utilities.
• Add targeted tests to CI that run the public PoC (in a sandbox) against built binaries to ensure regressions are visible before release.
• Communicate clearly with customers: if you ship an affected product, disclose whether pnm2png is present or not in shipped artifacts, and provide remediation guidance (remove binary, apply vendor update, rebuild).

---

Final thoughts and next steps for defenders​

CVE-2026-3713 is a reminder that security risk is not limited to core APIs or obvious network-facing services. Contrib utilities and demo tools can harbor memory-safety bugs with real operational impact—especially in complex modern environments where code is repackaged, statically linked, or run in automated pipelines.
Immediate actions for security teams:

• Conduct a targeted inventory for pnm2png and related libpng contrib binaries across your estate.
• Quarantine or restrict the utility until a vendor patch is available.
• Monitor vendor channels (distribution security trackers, libpng GitHub repository) and plan to apply patches as soon as they are released.
• Where possible, harden processing pipelines to accept only trusted image inputs or run untrusted conversions inside strong sandboxes and minimal-privilege containers.

This vulnerability is a manageable operational problem if treated promptly: the attack vector is local and the community already has a PoC and a clear technical diagnosis. The remaining risk is one of coordination—between upstream maintainers, distributors, packagers, and downstream product teams—to ensure the vulnerable code is removed or fixed and that affected binaries are updated consistently. Stay proactive: inventory first, mitigate quickly, and patch as soon as upstream or vendor updates become available. (github.com)
Conclusion: Treat pnm2png as untrusted until proven otherwise. Disable or remove the tool where possible, prioritize remediation for systems that process untrusted images automatically, and plan for coordinated updates once a canonical upstream fix is published.

---

Source: MSRC Security Update Guide - Microsoft Security Response Center