CVE-2026-33899

What it actually does

ImageMagick versions before the fixed releases contain an out-of-bounds write during XML parsing in the Magick component. A crafted XML-derived image or metadata file can cause ImageMagick to write a single zero byte outside the intended memory boundary. Based on the published scoring, the expected impact is limited to availability: the most likely result is a crash or abnormal termination of the ImageMagick process or the application invoking it. There is no stated confidentiality or integrity impact, and no public exploit maturity is reported.

Why it matters to the business

Organizations that use ImageMagick in web applications, media pipelines, document conversion services, thumbnail generation, content management systems, CI/CD jobs, or backend file-processing workflows could experience service instability or denial of service if untrusted files are processed. The current EPSS is low and stable, the issue is not in CISA KEV, and no ransomware use is reported, so this is not currently a top emergency; however, ImageMagick is commonly embedded in many downstream products and automation paths, so patching should still be prioritized wherever it processes user-supplied files.

How an attack unfolds

An attacker identifies an application or service that accepts uploaded images, documents, archives, or XML-based image formats and processes them with a vulnerable ImageMagick version. The attacker submits a specially crafted file that causes ImageMagick's XML parsing path to perform a one-byte out-of-bounds write. If the vulnerable parser path is reached, the ImageMagick worker process may crash, terminate the conversion job, or destabilize the calling application. Repeated submissions could be used to degrade availability of upload, preview, conversion, or media-processing services. There is currently no indication from the provided intelligence that this vulnerability is being actively exploited by named threat actors or that reliable public exploit code exists.

How to fix it

Upgrade ImageMagick to a fixed release. The advisory states the issue is fixed in ImageMagick 6.9.13-44 and 7.1.2-19, while the affected-version text also references versions below 7.1.2-189; verify the exact corrected package version from the upstream ImageMagick advisory or your operating system/package maintainer and deploy the latest available patched build for the active branch. If immediate upgrade is not possible, reduce exposure by blocking or tightly validating untrusted XML/XML-derived image inputs, disabling unnecessary ImageMagick coders via policy.xml, running ImageMagick in a sandboxed low-privilege worker, enforcing CPU/memory/time limits, and isolating file-conversion workloads from critical application processes.

How to confirm the fix worked

Confirm the deployed ImageMagick version using package-manager inventory and runtime checks such as `magick -version`, `convert -version`, or OS package queries. Verify that all application containers, build images, serverless layers, and bundled third-party tools that include ImageMagick have been rebuilt with the patched package. Test representative upload and conversion paths after the upgrade to ensure functionality remains intact. Where mitigations are used, confirm that ImageMagick policy.xml blocks unneeded XML-related coders and that resource limits and sandboxing are enforced for conversion workers.

Typical attack path

1. Find an internet-facing or remotely reachable workflow that processes user-controlled files with ImageMagick.
2. Determine whether XML-capable ImageMagick parsing is reachable through uploads, image conversion, metadata handling, thumbnailing, or document transformation.
3. Submit a crafted XML or XML-derived image/content file designed to trigger the out-of-bounds zero-byte write.
4. Cause the ImageMagick conversion process or the parent service to crash or fail the processing job.
5. Repeat submissions to create denial-of-service conditions against media-processing or upload functionality.

How to detect it

Look for evidence of attempted exploitation in web upload logs, API gateway logs, application logs for media-processing endpoints, job queue failures, container logs, crash dumps, system journals, and ImageMagick stderr/stdout logs. Focus on repeated conversion failures, segmentation faults, worker restarts, abnormal exits from `magick` or `convert`, and upload attempts involving XML or XML-derived formats immediately before a crash. Correlate suspicious requests with HTTP 5xx responses, queue retry storms, container restarts, kernel OOM/crash messages, and core dumps referencing ImageMagick, MagickCore, XML parsing, or libxml-related functions. Because no public exploit indicators or threat-actor-specific artifacts are provided, detection should be behavior-based rather than relying on fixed payload strings.

• AddressSanitizer: heap-buffer-overflow
• AddressSanitizer: global-buffer-overflow
• AddressSanitizer: stack-buffer-overflow
• runtime error: index out of bounds
• Segmentation fault
• segfault at
• core dumped
• magick
• convert
• MagickCore
• MagickWand
• policy.xml
• no decode delegate for this image format
• improper image header
• non-conforming drawing primitive definition
• XML_PARSE
• libxml

What your security team should do

• Inventory all direct and transitive uses of ImageMagick, especially services that process user-supplied uploads or externally sourced media.
• Patch to the fixed ImageMagick branch version or the latest vendor-supported package as part of the next regular security update cycle; accelerate patching for internet-facing upload/conversion services.
• Review ImageMagick policy.xml and disable unused coders and delegates, particularly those that expand attack surface through complex formats or external parsers.
• Run ImageMagick under least privilege with filesystem, network, CPU, memory, and execution-time restrictions.
• Add monitoring for repeated ImageMagick crashes, failed conversion jobs, malformed XML/image uploads, and spikes in upload-related 5xx responses.
• Ensure containers, base images, appliance packages, and embedded application dependencies are rebuilt rather than only patching host-level packages.