CVE-2026-53467

What it actually does

The MNG decoder in ImageMagick prior to 6.9.13-51 and 7.1.2-26 can leave portions of pixel data uninitialized while decoding an MNG image. When a crafted MNG file is processed, those unchanged pixel regions may contain residual heap memory from the ImageMagick process and may be exposed in the decoded image output or downstream transformations. The flaw is an information disclosure issue: it can leak limited process memory but does not directly provide code execution, data modification, or denial of service.

Why it matters to the business

Systems that accept or process untrusted image files with ImageMagick may unintentionally expose fragments of memory from image-processing workers. In practical terms, this could disclose small amounts of sensitive data that happened to be present in process memory, such as snippets of previously processed image content, metadata, application data, or secrets handled by the same process. The CVSS score is moderate and EPSS is currently low, with no known KEV listing or mature public exploitation noted, but exposure is still important for internet-facing upload, conversion, thumbnailing, document-rendering, or media-processing services.

How an attack unfolds

An attacker identifies a service or workflow that uses a vulnerable ImageMagick version to process user-supplied images. The attacker submits a specially crafted MNG file designed to trigger the decoder path where some pixel memory is not overwritten during decoding. If the application returns, stores, previews, converts, or otherwise exposes the processed image, the attacker retrieves the resulting output and inspects pixel regions for residual heap data. Because the bug leaks data opportunistically from process memory, results may vary by runtime behavior, prior workload, memory reuse, process isolation, and whether the service strips or re-encodes output. There is no indication from the supplied intelligence that this vulnerability is currently used by named threat actors, ransomware campaigns, or known exploited vulnerability programs.

How to fix it

Upgrade ImageMagick to a fixed release: 6.9.13-51 or later for the 6.x branch, or 7.1.2-26 or later for the 7.x branch. Update all operating system packages, container images, language bindings, and bundled copies that include ImageMagick or its command-line tools. If immediate upgrade is not possible, reduce exposure by disabling MNG input support where feasible, blocking MNG uploads, enforcing strict allow-lists for image formats, re-encoding images in an isolated and fully patched processing service, and running image processing in short-lived, least-privileged, sandboxed workers with no access to secrets. Restart long-lived image-processing processes after patching to ensure vulnerable code is no longer loaded.

How to confirm the fix worked

Confirm the installed ImageMagick version reports 6.9.13-51 or later, or 7.1.2-26 or later, using package manager inventory and ImageMagick runtime version checks such as `magick -version`, `convert -version`, or distribution-specific package queries. Verify that applications and containers are using the patched binary or library actually present in runtime paths, not an older bundled copy. Test upload and conversion controls to ensure MNG files are rejected if MNG support is intentionally disabled. For exposed services, submit a benign MNG test file and confirm processing behavior aligns with policy. Rebuild and redeploy dependent containers or packages, then restart workers and background jobs that may keep old libraries loaded.

Typical attack path

1. Find an application, API, batch pipeline, or content-management workflow that processes uploaded images using ImageMagick.
2. Confirm that MNG files are accepted directly or can reach ImageMagick through content-type confusion, file-extension handling, or automatic format detection.
3. Upload a crafted MNG image that exercises the vulnerable decoder behavior.
4. Cause the service to decode, transform, thumbnail, convert, or preview the submitted image.
5. Retrieve the generated image output or any stored derivative created by the service.
6. Inspect unchanged or anomalous pixel regions for leaked heap contents from the ImageMagick process.
7. Repeat with variations if the service permits multiple submissions, attempting to increase the chance of useful memory disclosure.

How to detect it

Retrospective detection is difficult because successful exploitation may look like ordinary image processing and the vulnerability does not create a unique file, process, registry key, or network beacon. Focus on log sources that record file uploads, content-type detection, image conversion jobs, command-line invocations, API requests, object storage writes, WAF events, and application errors. Search for MNG files or MNG content being uploaded or processed by ImageMagick before patching, especially from external or newly observed sources. Relevant artifacts include access logs showing uploads with `.mng` filenames, `image/x-mng` or related content types, ImageMagick command execution logs referencing MNG input, conversion outputs generated immediately after untrusted MNG submissions, and repeated requests that retrieve converted derivatives. If suspicious MNG processing is found, preserve the submitted files, converted outputs, application logs, worker stdout/stderr, and surrounding process telemetry for analysis. Because leaked data would be embedded in returned image output rather than a durable local artifact, review generated images and any externally served derivatives for anomalous pixel regions or unexpected embedded content.

What your security team should do

• Prioritize patching internet-facing upload, preview, media conversion, thumbnailing, document-processing, and content-management services that process untrusted images.
• Upgrade ImageMagick to 6.9.13-51 or later, or 7.1.2-26 or later, across hosts, containers, CI images, serverless layers, and application bundles.
• Temporarily block or quarantine MNG files at upload gateways, WAFs, API layers, mail/content filters, and media ingestion pipelines until patched.
• Inventory where ImageMagick is invoked indirectly through frameworks, CMS plugins, image-processing libraries, office document converters, and background workers.
• Run ImageMagick in sandboxed, least-privileged, ephemeral workers to reduce the value of any process-memory disclosure.
• Review image-processing logs for unexpected MNG handling, especially from untrusted sources or public endpoints, during the period before remediation.
• Add regression tests or policy checks that prevent unsupported image formats from reaching ImageMagick decoders.