CVE-2026-64685

What it actually does

CVE-2026-64685 is a heap buffer over-read in ImageMagick's BGR image decoder in versions before 7.1.2-27. When ImageMagick parses a specially crafted BGR image, the decoder can continue reading beyond the end of the input buffer because it does not consistently check for end-of-file conditions. The expected impact is limited information disclosure from process memory; the flaw is not described as enabling code execution or data modification.

Why it matters to the business

Systems that accept or process untrusted images with ImageMagick could expose small amounts of server-side process memory to an attacker through crafted image processing. The operational risk is highest for web applications, file conversion services, media pipelines, ticketing systems, CMS platforms, and APIs that automatically inspect or transform uploaded images. Current public risk signals are low: it is not listed in CISA KEV, is not associated with ransomware use, has low EPSS, and no exploit maturity is reported, but the issue is newly published and should still be patched during normal vulnerability management windows.

How an attack unfolds

An attacker identifies an application or service that uses a vulnerable ImageMagick version to parse user-supplied images. The attacker submits a specially crafted BGR image through an upload, conversion, thumbnailing, metadata extraction, or image validation workflow. When the vulnerable BGR decoder processes the file, it reads past the end of the supplied image buffer. Depending on how the application handles ImageMagick output and errors, this may disclose adjacent heap memory from the ImageMagick process. Exploitation does not require authentication if the image-processing endpoint is publicly reachable and accepts unauthenticated uploads; otherwise, the attacker needs whatever access is required to submit files to the processing workflow.

How to fix it

Upgrade ImageMagick to version 7.1.2-27 or later everywhere it is installed, including operating system packages, containers, language runtime bindings, statically bundled copies, and image-processing worker images. If immediate upgrade is not possible, reduce exposure by blocking or disabling BGR image decoding for untrusted inputs, restricting accepted image formats to a small allowlist, validating file types before processing, isolating ImageMagick execution in a sandboxed low-privilege worker, and preventing image-processing errors or raw output from being returned to users. Rebuild containers and redeploy services after the library update because long-running workers may continue using the vulnerable library until restarted.

How to confirm the fix worked

Confirm the deployed ImageMagick version with commands such as `magick -version`, `convert -version`, or package manager inventory and verify it reports 7.1.2-27 or later. Check all runtime locations, including containers, build images, serverless layers, bundled application dependencies, and hosts running background media workers. Validate that applications no longer invoke vulnerable binaries or libraries by checking executable paths and linked libraries. Where feasible, run a non-production regression test using representative BGR and malformed image inputs to confirm image processing fails safely without memory-safety sanitizer findings, abnormal output, or worker instability. Also confirm that upload allowlists and format restrictions are enforced if used as compensating controls.

Typical attack path

1. Find a public or internal application that accepts image uploads or performs image conversion using ImageMagick.
2. Determine or infer that the backend may invoke ImageMagick, MagickCore, MagickWand, convert, magick, or identify.
3. Create a malformed BGR image designed to trigger the decoder's missing end-of-file checks.
4. Upload or submit the crafted image to a vulnerable processing path.
5. Cause ImageMagick before 7.1.2-27 to parse the file and perform a heap buffer over-read.
6. Collect any disclosed data returned in generated output, error responses, logs, or downstream processing artifacts.

How to detect it

Look for evidence that untrusted BGR files or malformed image payloads were submitted to services that invoke ImageMagick. Useful sources include web access logs, API gateway logs, WAF logs, upload service logs, object storage write events, application logs from image conversion or thumbnail workers, ImageMagick stderr/stdout logs, container logs, crash reports, and EDR telemetry for `magick`, `convert`, or `identify` processes. Focus on requests that upload files with BGR-related extensions or content types, repeated image-processing failures, unusually small or malformed image files, and processing errors followed by responses containing unexpected binary data or memory-like output. In hardened or instrumented environments, search sanitizer logs for heap out-of-bounds reads in ImageMagick BGR decoding paths. Because the vulnerability may not reliably crash the process and no public exploitation campaign is identified, absence of crashes is not proof of non-exploitation.

• .bgr
• image/x-bgr
• magick
• convert
• identify
• heap-buffer-overflow
• heap buffer over-read
• READ of size
• AddressSanitizer
• BGR

What your security team should do

• Inventory all services, containers, and worker processes that use ImageMagick or linked MagickCore/MagickWand libraries.
• Prioritize upgrade to ImageMagick 7.1.2-27 or later for internet-facing upload, image conversion, thumbnailing, and file preview services.
• Restrict untrusted image processing to approved formats and consider disabling BGR decoding unless it is explicitly required.
• Ensure ImageMagick runs with least privilege in a sandboxed or containerized worker with no access to secrets, sensitive files, or internal metadata services.
• Review application behavior to ensure ImageMagick errors, raw parser output, and debug traces are not returned to end users.
• Search recent upload and processing logs for unusual BGR files, malformed image submissions, and repeated ImageMagick parser errors.
• Rebuild and redeploy container images and restart long-running services after patching to ensure the fixed library is actually loaded.