CVE-2026-56369

What it actually does

ImageMagick versions before 7.1.2-22 contain a cryptographic implementation flaw in the PasskeyEncipherImage method: AES-CTR encryption can reuse a nonce. In CTR mode, reusing the same key/nonce combination causes the keystream to repeat, allowing an attacker who can obtain multiple encrypted images produced under related conditions to compare ciphertexts and recover information about the underlying plaintext. The flaw is an information disclosure issue; it does not directly provide code execution, privilege escalation, integrity modification, or denial of service.

Why it matters to the business

Organizations that use ImageMagick to encrypt, transform, or process sensitive images may unintentionally expose image contents or metadata to an attacker able to collect affected encrypted outputs. The practical risk is constrained by the attack complexity and required conditions, and current public exploitation signals are low: EPSS is 0.00229, no known CISA KEV listing, no ransomware association, and no reported mature public exploit. However, ImageMagick is widely embedded in applications, pipelines, content-management systems, and backend media services, so the exposure may exist indirectly through downstream software even where ImageMagick is not user-facing.

How an attack unfolds

An attacker first identifies an application, service, or processing pipeline that uses a vulnerable ImageMagick version before 7.1.2-22 for passkey-based image encryption. The attacker then obtains or induces creation of multiple encrypted images where AES-CTR nonce reuse occurs under the vulnerable PasskeyEncipherImage implementation. Because CTR mode generates a stream of bytes that is XORed with plaintext, reusing the same nonce with the same effective key repeats the keystream. By comparing ciphertexts, and especially when the attacker knows or can guess parts of one image or its structure, they can derive portions of the keystream and recover corresponding plaintext information from another encrypted image. This is most useful against predictable image formats, standardized headers, templates, logos, forms, screenshots, or other images with known visual or file-structure elements.

How to fix it

Upgrade ImageMagick to version 7.1.2-22 or later wherever ImageMagick 7.x is deployed. If ImageMagick is bundled inside an application, container image, distribution package, language binding, or appliance, update the downstream package that carries the fixed ImageMagick build. Rebuild and redeploy container images and serverless artifacts that include vulnerable ImageMagick binaries or libraries. If immediate upgrade is not possible, avoid using the affected passkey-based image encryption feature for sensitive content, rotate any encryption keys or passkeys used with vulnerable outputs where feasible, and re-encrypt sensitive image archives with a fixed version using fresh keys/nonces. Treat previously encrypted sensitive images as potentially exposed if an attacker could have obtained multiple ciphertexts produced by the vulnerable implementation.

How to confirm the fix worked

Confirm the installed ImageMagick version reports 7.1.2-22 or later using package-manager inventory and runtime checks such as `magick -version` or `convert -version`, depending on deployment. Validate container images and application bundles, not only host operating-system packages, because ImageMagick is often embedded. Review SBOMs, dependency manifests, and distribution package changelogs for the fixed ImageMagick release or backported vendor patch. Test application workflows that perform encrypted image handling to ensure they continue functioning after upgrade. To assess exposure, identify whether passkey-based encrypted image functionality was used before remediation and whether encrypted image outputs were accessible to untrusted users, logs, object storage, caches, backups, or external recipients.

Typical attack path

1. Identify a system, application, container image, package, or media-processing workflow that includes ImageMagick before 7.1.2-22.
2. Determine whether the vulnerable passkey-based image encryption functionality is used, either directly by users or indirectly by application code.
3. Collect multiple encrypted image outputs generated by the vulnerable implementation under conditions that may reuse the AES-CTR nonce.
4. Use known plaintext, predictable image headers, repeated templates, or attacker-controlled sample images to infer keystream material.
5. Apply the recovered keystream relationships to other captured ciphertexts to recover partial plaintext content from encrypted images.
6. Use the disclosed image information for privacy violations, data theft, reconnaissance, or follow-on targeting.

How to detect it

This vulnerability is difficult to detect after the fact because successful exploitation is cryptanalytic and may not create distinctive logs, files, processes, or network signatures. Focus detection on evidence that an attacker accessed, downloaded, enumerated, or repeatedly generated encrypted image outputs from systems using vulnerable ImageMagick versions. Review web, API gateway, CDN, object-storage, application, and authentication logs for unusual bulk access to encrypted image files, repeated requests for image-encryption endpoints, high-volume downloads of similarly named encrypted assets, or suspicious access by unauthenticated or low-privileged users. Review application logs and job queues for repeated invocations of ImageMagick encryption workflows, especially with attacker-controlled input images. Examine shell history, EDR telemetry, and process execution logs for unusual use of ImageMagick commands around encrypted image conversion or passkey workflows. Forensic review should also identify whether encrypted image artifacts were exposed in public buckets, caches, backups, temporary directories, or support bundles. There are no reliable CVE-specific compromise indicators; detection should be behavior- and access-pattern based.

What your security team should do

• Inventory ImageMagick installations across servers, workstations, containers, CI/CD images, media services, and third-party applications.
• Prioritize upgrading any deployment that processes sensitive images, user-submitted images, identity documents, medical images, screenshots, forms, or confidential media.
• Upgrade to ImageMagick 7.1.2-22 or later, or apply a vendor package containing the equivalent backported fix.
• Rebuild and redeploy container images and application artifacts that include ImageMagick, then remove or quarantine older images from registries where practical.
• Determine whether passkey-based image encryption was used on sensitive data and assess whether affected encrypted outputs were accessible to unauthorized parties.
• For high-sensitivity use cases, re-encrypt affected image archives with a fixed version and fresh cryptographic material.
• Monitor vendor advisories for downstream software that bundles ImageMagick, since the vulnerability may be inherited indirectly.
• Because there is no KEV listing, ransomware association, or mature public exploit reported, handle as a targeted information-disclosure risk rather than an emergency remote-code-execution event, while still patching within normal cryptographic-fix SLAs.