Cloudanix VulnDB

CVE-2026-46523

Medium · 6.2

CVSS

6.2

EPSS

0.4%

Published

Jun 10, 2026

CISA due date

—

Cloudanix analysis

Next patch cycle SSVC: Track

A malicious image file can crash vulnerable image-processing software, potentially disrupting applications that handle uploaded or automated image conversions.

Exploitation
Local Privilege
Attacker needs
None
Complexity
Low
Impact
Denial Of Service
Component
Application
Class
Use After Free
Remediation
Upgrade
Effort
Medium
Patch risk
Low

What it actually does

A crafted ImageMagick MSL (Magick Scripting Language) image can trigger a heap use-after-free condition in vulnerable ImageMagick releases before 7.1.2.23 and 6.9.13-48. The assessed impact is primarily availability: processing the malicious image can crash the ImageMagick process or any application invoking ImageMagick libraries or command-line tools. The published CVSS vector indicates local attack conditions with no required privileges or user interaction and high availability impact, with no confirmed confidentiality or integrity impact.

Why it matters to the business

Organizations that process images with vulnerable ImageMagick versions may experience application crashes, failed media processing jobs, service instability, or denial of service if a malicious or malformed MSL file is processed. The current public exploitation signals are low: EPSS is 0.00301, exploit maturity is listed as none, and the issue is not in CISA KEV or associated with ransomware campaigns. However, ImageMagick is widely embedded in web applications, content management systems, document pipelines, CI jobs, and media services, so exposure can be indirect through dependent software that accepts or transforms uploaded images.

How an attack unfolds

An attacker first identifies an application, service, batch pipeline, or local workflow that processes attacker-supplied files using ImageMagick. They then craft an MSL image designed to trigger the heap use-after-free condition during parsing or conversion. If the application accepts the file directly, or if the attacker can place the file where a scheduled or automated image-processing job will pick it up, the vulnerable ImageMagick process attempts to parse it. Successful exploitation causes memory corruption that is expected to terminate or destabilize the ImageMagick process, producing a denial-of-service condition for the processing workflow or the application component that depends on it. There is no public indication from the provided intelligence that exploitation is currently mature, weaponized, KEV-listed, or used by named threat actors.

How to fix it

Upgrade ImageMagick to a fixed release: 7.1.2.23 or later for the 7.x branch, or 6.9.13-48 or later for the 6.x branch. Where ImageMagick is bundled by an operating system, container image, language package, appliance, or third-party application, apply the vendor-provided update rather than relying only on upstream version strings. If immediate upgrading is not possible, reduce exposure by disabling the MSL coder if it is not required, blocking or rejecting MSL inputs from untrusted sources, constraining file type handling to allowlisted image formats, running ImageMagick in a sandboxed and least-privileged worker, applying CPU/memory/time limits, and isolating image-processing workloads from critical services.

How to confirm the fix worked

Confirm the deployed ImageMagick version with package inventory and runtime checks such as `magick -version`, `convert -version`, or vendor package metadata. Validate that all application containers, build images, worker nodes, and third-party components that invoke ImageMagick have been updated to 7.1.2.23, 6.9.13-48, or a vendor-backported fixed build. If MSL is not required, verify policy configuration prevents MSL processing and test that files using the MSL coder are rejected. Review software composition and container scans for vulnerable ImageMagick packages. For production validation, confirm that image-processing services continue to function with expected formats while rejecting untrusted MSL content.

Typical attack path

  1. Identify an exposed application, API, upload function, automation job, or local workflow that processes images with ImageMagick.
  2. Determine whether MSL files or files interpreted as MSL can reach ImageMagick processing.
  3. Create a malformed MSL image that exercises the vulnerable parsing path.
  4. Submit, upload, or place the crafted file where the vulnerable ImageMagick process will parse it.
  5. Trigger processing through conversion, thumbnail generation, metadata extraction, or batch media handling.
  6. Cause the ImageMagick process or dependent application worker to crash, resulting in failed jobs or denial of service.

How to detect it

To assess whether this was already exploited, review application, web, object-storage, file-upload, and image-processing logs for MSL files or `msl:` coder usage from untrusted sources, especially immediately before ImageMagick worker failures. Correlate uploaded filenames, MIME types, request paths, user agents, and source IPs with crashes of `magick`, `convert`, `identify`, `mogrify`, or application workers that call ImageMagick. Examine system logs, service supervisor logs, container logs, kernel logs, and crash reporting systems for segmentation faults, aborts, heap-use-after-free reports, core dumps, or repeated restarts of ImageMagick-dependent workers. If AddressSanitizer, crash dumps, or EDR telemetry is available, search for heap-use-after-free findings involving ImageMagick or MSL parsing paths. Preserve suspicious uploaded files, conversion command lines, temporary files, core dumps, and container logs for forensic review. There are no known threat actors, KEV exploitation, ransomware usage, or public mature exploit indicators in the provided intelligence, so detection should focus on suspicious MSL processing followed by process instability rather than known campaign-specific infrastructure.

  • msl:
  • .msl
  • MSL
  • <image
  • <read filename=
  • <write filename=
  • AddressSanitizer: heap-use-after-free
  • heap-use-after-free
  • Segmentation fault
  • core dumped
  • coders/msl.c
  • magick
  • convert
  • identify
  • mogrify

What your security team should do

  • Inventory all direct and transitive ImageMagick usage, including operating system packages, containers, CI/CD images, media-processing workers, document converters, CMS plugins, and third-party applications.
  • Prioritize patching systems that process untrusted user-supplied files, especially internet-facing upload, thumbnailing, document conversion, or media ingestion services.
  • Upgrade to ImageMagick 7.1.2.23 or later, 6.9.13-48 or later, or the appropriate vendor-backported fixed package.
  • Disable the MSL coder where it is not explicitly required, and enforce strict allowlists for accepted input formats.
  • Run ImageMagick workloads with least privilege, sandboxing, filesystem restrictions, and resource limits to reduce denial-of-service impact.
  • Monitor for crashes or abnormal termination of ImageMagick-related processes after suspicious file processing events.
  • Because this is not KEV-listed, has low EPSS, and has no known mature exploit in the provided intelligence, handle as priority patching for exposed image-processing services rather than emergency response across all assets.

The record

ImageMagick is free and open-source software used for editing and manipulating digital images. Prior to versions 7.1.2.23 and 6.9.13-48, a crafted MSL image can trigger a heap-use-after-free. Versions 7.1.2.23 and 6.9.13-48 fix the issue.

Affected packages

Ecosystem Package Introduced Fixed
openSUSE:Leap 16.0 GraphicsMagick 0 1.3.45-160000.8.1
openSUSE:Leap 16.0 ImageMagick 0 7.1.2.0-160000.10.1
openSUSE:Tumbleweed GraphicsMagick 0 1.3.47-3.1
openSUSE:Tumbleweed ImageMagick 0 7.1.2.25-2.1

Related vulnerabilities