CVE-2026-61862

What it actually does

This vulnerability is a low-severity out-of-bounds read in ImageMagick's handling of image profiles when using the `identify` command with debug output enabled. If a profile contains a non-printable value, ImageMagick may read one byte beyond the end of the profile buffer and print that byte in debug output. The flaw can disclose a very small amount of adjacent process memory, but it does not provide code execution, privilege escalation, file write, or denial-of-service capability based on the available information.

Why it matters to the business

The practical risk is limited, but systems or services that process untrusted images with ImageMagick debug logging enabled could accidentally expose small fragments of memory in logs or command output. This may matter for regulated environments or workflows where image processing occurs near sensitive metadata, secrets, or user-supplied content. The vulnerability is not known to be exploited, is not in the CISA KEV catalog, has very low EPSS probability, and has no known ransomware association, so remediation should be handled through normal patch management unless debug-enabled image processing is exposed to untrusted input.

How an attack unfolds

An attacker would need a path to influence an image file processed by ImageMagick and cause the `identify` command to run with debug output enabled. The attacker crafts or supplies an image containing a profile with a non-printable value positioned so that ImageMagick's profile-display logic reads one byte beyond the profile boundary. When the vulnerable version processes the file, the extra byte may be emitted in debug output. The attacker must then be able to view that debug output, application logs, job logs, or command output to recover the leaked byte. Because only a single byte is disclosed per triggering condition and debug output is required, exploitation is high-friction and impact is generally limited.

How to fix it

Upgrade ImageMagick to a fixed release: 7.1.2-26 or later for ImageMagick 7.x, or 6.9.13-51 or later for ImageMagick 6.x. Where packaged by an operating system or distribution vendor, install the vendor-provided fixed package even if the displayed upstream version differs due to backporting. As a mitigation, disable ImageMagick debug output for production image-processing paths, avoid exposing `identify` debug output to users, and restrict processing of untrusted images to isolated, least-privileged environments. Review wrappers, CI jobs, media-processing services, and background workers for command invocations that include debug flags or verbose diagnostic logging.

How to confirm the fix worked

Confirm the installed ImageMagick version is fixed by running `magick -version`, `identify -version`, or the package manager's version query and verifying ImageMagick 7.x is at least 7.1.2-26 or ImageMagick 6.x is at least 6.9.13-51, accounting for vendor backports. Search application code, job definitions, containers, scripts, and service configurations for `identify` or `magick identify` invocations using debug options. Validate that production processing of untrusted images does not enable debug output and that logs do not expose raw ImageMagick diagnostic output to end users. If vendor packages are used, confirm the relevant security advisory or changelog includes the fix for this issue.

Typical attack path

1. Identify an application, pipeline, or automation task that uses ImageMagick `identify` on attacker-controlled images.
2. Determine or infer that ImageMagick debug output is enabled and that command output or logs are accessible to the attacker or retained for later review.
3. Submit a crafted image containing a malformed or specially constructed profile with non-printable profile data.
4. Trigger processing by a vulnerable ImageMagick version earlier than 7.1.2-26 or 6.9.13-51.
5. Inspect debug output or logs for the extra byte printed past the end of the profile boundary.
6. Repeat with variations if attempting to infer additional adjacent memory content, subject to significant practical limitations.

How to detect it

Detection should focus on whether vulnerable ImageMagick versions processed untrusted files with debug output enabled and whether any debug output was exposed or logged. Review application logs, batch-job logs, CI logs, container stdout/stderr, web upload processing logs, and centralized logging for `identify` or `magick identify` executions that include debug options. Look for suspicious or repeated processing of images with embedded profiles, malformed profile warnings, non-printable profile output, or attacker-controlled uploads followed by verbose ImageMagick diagnostic output. Because the leak is only a single byte and no public exploitation is known, there may be no reliable exploit-specific artifact. Investigations should correlate image upload events, command execution telemetry, debug log emission, and access to resulting logs or job output.

• identify -debug
• magick identify -debug
• -debug All
• -debug Trace
• -debug Configure
• -debug Coder
• -debug Blob
• identify -verbose
• magick identify -verbose
• ImageMagick identify
• profile:
• Profile-
• non-printable
• identify -version
• magick -version
• ImageMagick 7.1.2-25
• ImageMagick 7.1.2-24
• ImageMagick 6.9.13-50
• ImageMagick 6.9.13-49

What your security team should do

• Inventory systems, containers, build images, serverless functions, and application dependencies that include ImageMagick or call `identify`.
• Prioritize patching internet-facing or multi-tenant image-processing workflows, especially those accepting untrusted image uploads.
• Upgrade to ImageMagick 7.1.2-26 or later, or 6.9.13-51 or later, using vendor-supported packages where applicable.
• Disable debug output in production ImageMagick usage and remove unnecessary `-debug` flags from scripts, wrappers, and application code.
• Restrict access to image-processing logs because exploitation requires visibility into debug output.
• Run image processing under least-privileged accounts and sandboxing controls to reduce the impact of malformed file handling generally.
• Treat this as routine-priority remediation for most environments because there is no known exploitation, no KEV listing, no ransomware association, and very low EPSS probability.