CVE-2026-33900

What it actually does

ImageMagick versions before 7.1.2-19 and 6.9.13-44 contain an integer truncation/wraparound flaw in the VIFF image encoder on 32-bit builds. When ImageMagick is asked to encode a specially crafted or attacker-controlled image to VIFF, size calculations can wrap and lead to an out-of-bounds heap write. The disclosed impact is primarily availability loss through process crash; reliable code execution has not been established, and exploitation appears constrained by 32-bit builds and the need to reach the VIFF encoding path.

Why it matters to the business

Systems that automatically process untrusted images may be vulnerable to denial of service if they use affected 32-bit ImageMagick builds and permit conversion to VIFF. A successful attack could crash image-processing workers, interrupt thumbnailing, document conversion, media ingestion, or other image-handling workflows. The CVSS score is moderate, EPSS is low and flat, it is not in CISA KEV, and no public exploit maturity is reported, so urgency is lower than for actively exploited issues, but internet-facing or high-volume image processing services should still patch during the next maintenance cycle.

How an attack unfolds

An attacker first identifies an application, service, API, or batch workflow that accepts image content and processes it with ImageMagick on a 32-bit build. The attacker then supplies an image or conversion request designed to make ImageMagick encode output using the VIFF encoder with dimensions or metadata that cause an internal integer calculation to truncate or wrap. When the vulnerable encoder allocates or indexes heap memory based on the wrapped value, subsequent writes can occur outside the intended heap buffer. In known public information, the practical result is expected to be a crash of the ImageMagick process or the worker process embedding the library, causing denial of service. There is no indication that this vulnerability is currently used by named threat actors, ransomware campaigns, or broad exploitation campaigns.

How to fix it

Upgrade ImageMagick to a fixed release: 7.1.2-19 or later for the 7.x branch, or 6.9.13-44 or later for the 6.x branch. Prioritize 32-bit deployments and any service that processes untrusted images. If immediate upgrade is not possible, mitigate by disabling VIFF encoding/decoding where not required through ImageMagick policy controls, restricting supported output formats, rejecting VIFF conversion requests from untrusted users, enforcing strict resource limits for ImageMagick operations, isolating image-processing workers, and ensuring crash-restart limits prevent repeated denial-of-service loops. Prefer 64-bit builds where feasible, but do not treat architecture change alone as a substitute for applying the fixed version.

How to confirm the fix worked

Confirm the installed ImageMagick version with `magick -version`, `convert -version`, or package-manager inventory and verify it is at least 7.1.2-19 or 6.9.13-44. Confirm whether the deployed build is 32-bit or 64-bit using OS package metadata, container image architecture, or binary inspection. Review ImageMagick policy files to ensure VIFF is disabled if it is not business-required. Validate that applications cannot request VIFF output unless explicitly intended. After patching or mitigation, run representative image-conversion tests and verify no service crash occurs. For packaged deployments, ensure all containers, serverless images, base images, and downstream applications bundling ImageMagick have been rebuilt against the fixed package.

Typical attack path

1. Find an exposed image upload, conversion, thumbnailing, or media-processing feature that uses ImageMagick.
2. Determine or infer that the backend is running an affected 32-bit ImageMagick version below 7.1.2-19 or 6.9.13-44.
3. Submit crafted image data or a conversion request that reaches the VIFF encoder path.
4. Trigger an integer wraparound during VIFF output size or buffer calculations.
5. Cause an out-of-bounds heap write that crashes the ImageMagick process or dependent worker service.
6. Repeat requests to create sustained degradation or denial of service.

How to detect it

There are no known unique exploitation artifacts, named threat actor procedures, ransomware associations, or public exploit indicators for this issue. To assess possible prior exploitation, review application, web server, API gateway, job queue, and worker logs for image upload or conversion requests immediately preceding crashes of ImageMagick-based processes. Correlate process supervisor logs, systemd journal entries, container runtime events, core dump records, kernel logs, and application exception traces for heap corruption, segmentation faults, aborts, or out-of-bounds write reports involving `magick`, `convert`, ImageMagick libraries, or the VIFF encoder. Pay particular attention to requests specifying VIFF output, files with `.viff` or `.xv` extensions, unusually large image dimensions, repeated failed conversions from the same source, and denial-of-service patterns targeting image endpoints. If core dumps are available, inspect stack traces for ImageMagick VIFF encoder functions such as `WriteVIFFImage` or references to VIFF coder source files. Treat these as suspicious behavioral indicators rather than definitive proof of exploitation.

• WriteVIFFImage
• viff.c
• VIFF
• image/viff
• .viff
• .xv
• magick
• convert
• heap-buffer-overflow
• out-of-bounds heap write
• malloc(): corrupted top size
• corrupted double-linked list
• free(): invalid next size
• Segmentation fault
• SIGSEGV
• SIGABRT
• AddressSanitizer
• MagickCore
• MagickWand

What your security team should do

• Inventory all uses of ImageMagick, including OS packages, containers, language bindings, embedded vendor tools, CI/CD image-processing jobs, and media-conversion services.
• Prioritize patching 32-bit deployments and internet-facing or externally supplied image-processing paths to ImageMagick 7.1.2-19 or 6.9.13-44 or later.
• Disable VIFF support if it is not required, and restrict allowed image output formats for untrusted users.
• Apply ImageMagick resource limits for memory, map, disk, dimensions, width, height, area, and time to reduce denial-of-service blast radius.
• Monitor for repeated crashes of `magick`, `convert`, web workers, queue workers, or media-processing services correlated with image upload or conversion requests.
• Rebuild and redeploy container images and application packages that bundle vulnerable ImageMagick libraries rather than relying only on host-level patching.
• Because EPSS is low, KEV is false, and no exploit maturity is reported, schedule remediation based on exposure: urgent for public untrusted image processing, routine for internal-only or non-32-bit use.