ImageMagick CVE-2026-105083

Exploitation requires that ImageMagick's security policy file (policy.xml) contain a DOCTYPE declaration whose syntax does not end in ']>' - the exact condition that causes LoadPolicyCache to consume the rest of the file and apply no rules. This presupposes (1) a deployment that actually relies on policy.xml for hardening, and (2) an actor able to write or influence that privileged configuration file, or an administrator who inadvertently authors such a DOCTYPE. Limiting factors: the bug is local/config-only (not remotely reachable), requires high privileges over the config, and has no effect on default installs that ship no restrictive policy.xml; it does not directly grant code execution but silently disables intended restrictions.

This is a genuinely low-priority issue, and the signals largely agree. The vendor CVSS 4.0 vector (AV:L/AC:H/AT:P/PR:H) yields a 1.8 score, reflecting that exploitation requires local access, high privileges, a present attack requirement, and high complexity - all consistent with a flaw in how the policy.xml hardening file is parsed. There is no EPSS score provided, no CISA KEV listing, and no public POC, so no signal points to active or imminent exploitation. The real-world concern is not a remote attacker gaining access but a fail-open security control: an administrator who deploys a policy.xml using an alternate DOCTYPE (one not ending in ']>') will have ALL policy rules silently skipped, re-enabling restricted coders/operations (e.g., the MVG/MSL/HTTPS delegates historically abused in ImageMagick exploits) without any error. The practical risk is therefore indirect - it weakens a defensive mitigation rather than directly granting attacker capability, which is why CVSS is correctly low. The main caveat: the low CVSS assumes an attacker must author the malicious policy.xml (PR:H), but the more realistic danger is an administrator unknowingly triggering the fail-open via a legitimate-looking DOCTYPE, which the base score does not capture.

An administrator hardens ImageMagick by writing a policy.xml that forbids dangerous coders and delegates, but uses a DOCTYPE declaration that does not terminate with ']>'. On load, LoadPolicyCache consumes the remainder of the file and applies zero rules, so the intended restrictions never take effect; a subsequent untrusted image or MSL/MVG payload can then invoke operations the policy was supposed to block. No public exploit code is identified, and triggering it requires control over or an error in the privileged policy configuration file.