CVE-2026-3713

What it actually does

CVE-2026-3713 is a local heap-based buffer overflow in the libpng contrib utility pnm2png, specifically in do_pnm2png in contrib/pngminus/pnm2png.c. Maliciously crafted PNM input that manipulates width and height values can cause the utility to allocate or address memory incorrectly and write past the bounds of a heap buffer. Successful exploitation can crash the process and may allow corruption of process memory with potential local code execution in the context of the user or service account running pnm2png. The issue affects libpng versions up to and including 1.6.55, but the vulnerable component is the contrib pngminus conversion utility rather than the core PNG decoding path used by most libpng consumers.

Why it matters to the business

The most likely operational impact is denial of service or compromise of systems that automatically convert untrusted PNM images using pnm2png. Risk is lower than remotely exploitable server vulnerabilities because exploitation requires local execution or a workflow that feeds attacker-controlled files into the utility. However, organizations that run image-conversion pipelines, CI jobs, content-processing services, or user-submitted media workflows with pnm2png may face service disruption, data exposure, or lateral movement if the utility runs with elevated privileges. Exploit availability increases urgency for exposed conversion workflows, though the very low EPSS score and lack of KEV listing indicate limited observed exploitation at this time.

How an attack unfolds

An attacker first gains the ability to place or submit a crafted PNM file to a system that runs the libpng contrib pnm2png utility. The file contains malicious width and height fields designed to trigger incorrect heap buffer sizing or indexing in do_pnm2png. When pnm2png processes the file, it performs memory operations based on those manipulated dimensions and writes beyond the allocated heap buffer. In a simple case, the process terminates with a heap corruption crash. In a more advanced case, the attacker attempts to shape heap memory so the overflow alters control data or adjacent objects, potentially gaining code execution with the privileges of the process invoking pnm2png. This is most relevant where pnm2png is used in automated processing of untrusted images rather than one-off local administrative use.

How to fix it

Inventory systems and build artifacts that include or install the libpng contrib pngminus pnm2png utility. Because no fixed version was provided in the input and the upstream project had reportedly not responded at disclosure time, treat libpng versions up to and including 1.6.55 as affected for this component. If an official patched release becomes available, upgrade libpng and any packaged pnm2png binary to that fixed release. Until then, remove or disable pnm2png where it is not required, avoid compiling or distributing contrib/pngminus tools, and replace pnm2png with a maintained converter that safely validates image dimensions. Do not process untrusted PNM files with pnm2png. If the utility must remain in use, run it with least privilege, inside a sandbox or container, with memory/process limits, isolated temporary directories, and no access to sensitive files or network resources. Add pre-validation for PNM dimensions and reject unusually large, negative, malformed, or inconsistent width/height values before conversion.

How to confirm the fix worked

Confirm whether pnm2png is present by searching installed packages, build outputs, container images, and application dependencies for pnm2png or contrib/pngminus. Verify the linked or bundled libpng version and treat versions up to 1.6.55 as exposed if pnm2png is available. Review image-processing scripts, cron jobs, CI/CD jobs, upload handlers, and batch conversion workflows for calls to pnm2png. After remediation, confirm that pnm2png is removed, inaccessible to untrusted workflows, replaced, sandboxed, or upgraded to a patched build once available. Test controls by submitting benign PNM files with boundary-case dimensions to ensure they are rejected before reaching pnm2png. For hardened deployments, confirm that process confinement, resource limits, and least-privilege execution are active and that crashes cannot expose sensitive data or affect broader services.

Typical attack path

1. Identify a host, job, script, package, or service that invokes the pnm2png utility from libpng contrib/pngminus.
2. Create a malformed PNM image with crafted width and height values intended to trigger the heap-based buffer overflow.
3. Deliver the file through local access, a file drop location, CI artifact, image-upload workflow, batch conversion directory, or another mechanism that causes pnm2png to process it.
4. Wait for pnm2png to parse the malicious PNM file and enter do_pnm2png with attacker-controlled dimensions.
5. Trigger heap memory corruption, usually causing a crash and potentially enabling code execution if the attacker can control heap layout and execution flow.
6. Use any resulting code execution in the context of the pnm2png process to read accessible files, modify generated output, disrupt processing, or move further within the local environment.

How to detect it

Look for evidence that pnm2png processed attacker-controlled or malformed PNM files and then crashed or behaved abnormally. Relevant sources include process execution telemetry, EDR events, Linux auditd logs, shell history, cron and CI job logs, application upload/conversion logs, container logs, systemd journal entries, kernel logs, core dump records, and crash reporting systems. Search for executions of pnm2png against files in writable or externally influenced locations such as upload directories, temporary directories, build workspaces, shared folders, and CI artifact paths. Investigate crashes with heap-corruption signatures, segmentation faults, aborts from malloc/free consistency checks, AddressSanitizer reports, or repeated conversion failures involving PNM files. If core dumps are available, examine the crashing process name, command line, working directory, input file path, and stack traces referencing do_pnm2png or contrib/pngminus/pnm2png.c. Because exploitation is local and no specific threat actor activity or KEV exploitation is reported, detection should focus on abnormal local execution and crash artifacts rather than network indicators.

• pnm2png
• contrib/pngminus/pnm2png.c
• do_pnm2png
• AddressSanitizer: heap-buffer-overflow
• heap-buffer-overflow
• malloc(): corrupted top size
• malloc(): invalid size
• free(): invalid next size
• corrupted size vs. prev_size
• double free or corruption
• Segmentation fault
• SIGSEGV
• SIGABRT
• core dumped
• /usr/bin/pnm2png
• /usr/local/bin/pnm2png

What your security team should do

• Prioritize systems that automatically process user-supplied or externally sourced PNM images using pnm2png, even though the vulnerability is local-only.
• Remove or disable the pnm2png utility where it is not explicitly required, especially from production images and shared processing hosts.
• If pnm2png is required, isolate it in a sandboxed container or restricted execution profile with no unnecessary file, credential, or network access.
• Block untrusted PNM input or add strict validation of PNM width, height, file size, and format consistency before conversion.
• Track upstream and distribution advisories for a fixed libpng release or backported patch, then upgrade promptly once available.
• Search logs and crash telemetry for evidence of pnm2png crashes, heap corruption, or suspicious image-conversion failures since the publication date.
• Add monitoring for unexpected pnm2png executions, especially from web services, upload directories, temporary directories, CI runners, and scheduled jobs.
• Rebuild container images and static binaries that may have bundled libpng contrib tools rather than relying only on operating-system package updates.