CVE-2026-61859

What it actually does

ImageMagick versions before 7.1.2-26 and 6.9.13-51 contain a missing security policy enforcement check in the -script operation. A user or process that can invoke ImageMagick locally with crafted script input can cause ImageMagick to read files from filesystem paths that would otherwise be blocked by the configured policy.xml security policy. The vulnerability is limited to confidentiality impact: it enables unauthorized local file reads through a policy bypass, but does not by itself provide code execution, privilege escalation, or file modification.

Why it matters to the business

Systems that rely on ImageMagick policy restrictions to prevent access to sensitive local files may expose confidential data if untrusted users, workloads, or automation can run ImageMagick commands. The operational risk is highest in shared hosting, CI/CD, document conversion, media processing, and multi-tenant application environments where ImageMagick is available to lower-privileged users or invoked on attacker-controlled inputs. The current public exploitation signal is low: EPSS is 0.00124, it is not listed in CISA KEV, and no exploit maturity is reported, but the issue should still be remediated where ImageMagick processes untrusted content.

How an attack unfolds

An attacker first needs the ability to execute ImageMagick locally or influence an application workflow that invokes ImageMagick with attacker-controlled arguments or script content. They craft use of the -script operation so that ImageMagick processes commands through the vulnerable path. Because the vulnerable code path does not apply the expected security policy checks, ImageMagick may read a file path that policy.xml would normally deny. The attacker then obtains the contents through command output, generated image metadata, conversion artifacts, application responses, logs, or another place where ImageMagick output is exposed. Successful exploitation depends on local execution or control over an ImageMagick invocation and on the target file being readable by the operating-system user running ImageMagick.

How to fix it

Upgrade ImageMagick to a fixed release: 7.x users should upgrade to 7.1.2-26 or later, and 6.9.13.x users should upgrade to 6.9.13-51 or later. If using operating-system packages, apply the vendor security update for ImageMagick and confirm the backported package contains the fix. Where immediate upgrade is not possible, reduce exposure by preventing untrusted users from invoking ImageMagick directly, avoiding attacker-controlled use of the -script operation, running ImageMagick in a sandbox/container with least-privilege filesystem access, and ensuring the operating-system account running ImageMagick cannot read sensitive files. Do not rely solely on ImageMagick policy.xml restrictions as the only boundary for sensitive local files until patched.

How to confirm the fix worked

Confirm the installed ImageMagick version with commands such as `magick -version`, `convert -version`, or package-manager queries, and verify it is 7.1.2-26 or later for the 7.x branch, or 6.9.13-51 or later for the 6.9.13 branch. Validate that applications and background workers are using the patched binary actually present in their runtime path, not an older bundled or container image copy. Review package manifests, container images, build pipelines, and base images for vulnerable ImageMagick versions. Where feasible in a controlled test environment, attempt to use the -script operation to read a path blocked by policy.xml and confirm the operation is denied after remediation.

Typical attack path

1. Identify a system or application workflow that uses a vulnerable ImageMagick version.
2. Gain local command execution as a low-privileged user or find a feature that passes attacker-controlled input to ImageMagick.
3. Invoke ImageMagick with the -script operation and crafted script content referencing a file path normally blocked by ImageMagick policy.
4. Abuse the missing policy check to cause ImageMagick to read the restricted file path.
5. Recover the disclosed file contents from ImageMagick output, generated artifacts, application responses, or logs.

How to detect it

To determine whether this was already exploited, review command execution telemetry, EDR process events, shell history, application logs, job runner logs, web server logs, and container runtime logs for ImageMagick executions using the -script argument, especially where paired with attempts to access sensitive or policy-denied paths. Focus on processes named magick, convert, identify, mogrify, composite, montage, or animate. Look for ImageMagick invocations by unexpected users, from web application worker accounts, CI jobs, upload-processing services, or temporary directories. Investigate generated output files, conversion artifacts, application responses, and logs that may contain contents of local files. Since this vulnerability enables file read rather than code execution, durable host artifacts may be minimal; detection is primarily based on suspicious command-line arguments, access to sensitive paths by ImageMagick processes, and unexpected disclosure of file contents.

• -script
• magick -script
• convert -script
• identify -script
• mogrify -script
• composite -script
• montage -script
• animate -script
• /etc/passwd
• /etc/shadow
• /etc/hosts
• /proc/self/environ
• /proc/self/cmdline
• /root/.ssh/id_rsa
• /home/*/.ssh/id_rsa
• C:\\Windows\\System32\\config\\SAM
• C:\\Windows\\System32\\config\\SYSTEM
• C:\\Users\\*\\.ssh\\id_rsa
• policy.xml

What your security team should do

• Inventory ImageMagick installations across servers, containers, CI runners, developer workstations, and application dependencies.
• Prioritize upgrades on systems that process untrusted images, documents, PDFs, or media, especially shared or multi-user environments.
• Upgrade to ImageMagick 7.1.2-26 or later, or 6.9.13-51 or later, using vendor-supported packages where available.
• Search application code, scripts, job definitions, and logs for use of ImageMagick -script and restrict or remove untrusted access to that operation.
• Run ImageMagick workloads with least privilege and filesystem isolation so the ImageMagick process cannot read secrets, credentials, private keys, or sensitive application files.
• Monitor for suspicious ImageMagick executions that include -script and references to sensitive filesystem paths.
• Because this is not KEV-listed and has low EPSS, treat it as important hardening rather than emergency internet-wide response unless ImageMagick is exposed through untrusted processing workflows.