CVE-2026-40312

What it actually does

An off-by-one error in ImageMagick's MSL decoder can cause an out-of-bounds condition when ImageMagick reads a crafted Magick Scripting Language file. The documented impact is process crash, resulting in denial of service for the ImageMagick invocation or any application, worker, queue consumer, or service that relies on ImageMagick for image processing. No confidentiality or integrity impact is currently described, and there is no public evidence of code execution or active exploitation in KEV.

Why it matters to the business

Systems that process untrusted images or scripts with ImageMagick may become unstable if a malicious MSL file is accepted, potentially interrupting image upload, conversion, thumbnailing, document processing, media pipelines, or batch jobs. The risk is most relevant where ImageMagick is exposed through automated processing of user-supplied files. EPSS is currently very low and stable, the issue is not in CISA KEV, and no mature exploit is reported, so remediation should be scheduled promptly but generally below actively exploited vulnerabilities.

How an attack unfolds

An attacker prepares a malformed MSL file that triggers the off-by-one error in the MSL decoder. The attacker then gets ImageMagick to read that file, either by running it locally, submitting it to an application that accepts files for conversion, or abusing a workflow that invokes ImageMagick on attacker-controlled content. When ImageMagick parses the file, the vulnerable decoder condition is reached and the process crashes. If the affected process is part of a web application, upload pipeline, queue worker, or batch conversion system, repeated submissions can cause recurring processing failures and service degradation.

How to fix it

Upgrade ImageMagick to version 7.1.2-19 or later. Where ImageMagick is installed through an operating system package manager, apply the vendor-provided security update that backports the fix, even if the displayed upstream version differs. If immediate upgrade is not possible, reduce exposure by blocking untrusted MSL input, disabling the MSL coder where operationally feasible through ImageMagick policy configuration, restricting accepted file types to known-safe formats, validating uploads before processing, running ImageMagick in a sandbox with memory and CPU limits, and ensuring worker supervisors automatically restart failed jobs without allowing unbounded retry storms.

How to confirm the fix worked

Confirm all ImageMagick binaries and linked libraries used by applications report a fixed version, preferably 7.1.2-19 or later, using package inventory, container image scans, and runtime checks such as `magick -version`. Verify that application paths invoking ImageMagick do not allow untrusted MSL files unless required. Review ImageMagick `policy.xml` to confirm unwanted coders are disabled if mitigation is used. In staging, run representative image-processing workflows after upgrade to ensure compatibility. For exposure validation, search repositories, container images, job definitions, and service configurations for ImageMagick usage and for commands that allow `msl:` input or unrestricted file conversion.

Typical attack path

1. Identify an application, service, or workflow that uses ImageMagick to process user-supplied files.
2. Determine whether MSL files, file names, or ImageMagick coders/delegates can be passed into the processing path.
3. Craft a malicious MSL file designed to trigger the MSL decoder off-by-one error.
4. Submit or place the malicious file where the vulnerable ImageMagick version will read it.
5. Trigger image processing and cause the ImageMagick process or dependent worker to crash.
6. Repeat submissions to sustain denial of service or disrupt processing queues.

How to detect it

Look for signs of abnormal ImageMagick crashes or repeated failed conversions involving MSL input. Useful sources include application upload logs, media conversion service logs, worker or queue logs, web access logs for file-upload endpoints, process supervisor logs, systemd/journald entries, container stdout/stderr, crash dumps, core dump records, and EDR process telemetry. Search for ImageMagick executions that reference `msl:` or files ending in `.msl`, especially when followed by segmentation faults, aborts, non-zero exits, worker restarts, or conversion queue retries. Because the known impact is denial of service rather than persistence or data theft, focus on availability symptoms: sudden spikes in failed image-processing jobs, repeated submissions from the same source, unexpected core files from `magick` or related ImageMagick tools, and application errors around thumbnail or conversion generation. No named threat actors, ransomware use, or KEV exploitation are currently associated with this issue.

• msl:
• .msl
• MSL
• Magick Scripting Language
• magick
• convert
• identify
• composite
• Segmentation fault
• core dumped
• AddressSanitizer
• heap-buffer-overflow
• ImageMagick

What your security team should do

• Inventory ImageMagick installations across hosts, containers, build images, and application dependencies, prioritizing externally reachable upload and media-processing services.
• Upgrade ImageMagick to 7.1.2-19 or the relevant vendor-patched package version.
• If upgrade cannot be completed quickly, temporarily block or disable MSL processing and restrict accepted upload formats.
• Add resource limits, sandboxing, and worker restart controls around ImageMagick execution to reduce denial-of-service impact.
• Review logs for recent unexplained ImageMagick crashes, failed conversions, queue spikes, or repeated processing attempts involving MSL content.
• Add regression tests or security tests to ensure untrusted MSL files are rejected unless explicitly required.
• Track vendor advisories for downstream packages because operating system distributions may ship backported fixes under older version numbers.