CVE-2026-49219

What it actually does

The flaw is a local, low-complexity path traversal/policy bypass in ImageMagick filename parsing. Prior to ImageMagick 6.9.13-48 and 7.1.2-24, crafted input involving a symlink can cause ImageMagick to read files that should have been blocked by its security policy. The primary impact is unauthorized local file disclosure to a user or process that can invoke ImageMagick or influence files processed by it. The CVSS vector indicates local access and low privileges are required, with high confidentiality impact and no expected integrity or availability impact.

Why it matters to the business

Organizations that use ImageMagick in image-processing workflows may unintentionally expose sensitive local files if an attacker can submit or control images, filenames, archives, or symlink structures processed by the application. This can lead to leakage of configuration files, secrets, credentials, source code, or private data accessible to the ImageMagick process. Although this issue is not currently in CISA KEV, has low EPSS, and no public exploit maturity is reported, ImageMagick is widely embedded in web applications, media pipelines, document conversion services, CMS platforms, and downstream packages, so exposure can be indirect and easy to overlook.

How an attack unfolds

An attacker first needs a way to cause ImageMagick to process attacker-controlled file paths or a directory structure that includes symbolic links. This may occur through a local account, a shared processing directory, a CI/media pipeline, or an application feature that accepts uploaded content and invokes ImageMagick. The attacker creates a symlink that points to a file normally restricted by ImageMagick security policy, then supplies a crafted filename or path that is parsed incorrectly. When ImageMagick processes the crafted reference, the policy check can be bypassed and the target file may be read despite policy restrictions. The attacker then retrieves the disclosed content through command output, generated image metadata/output, application responses, temporary files, logs, or another workflow-specific side channel.

How to fix it

Upgrade ImageMagick to a patched release: 6.9.13-48 or later for the 6.x branch, or 7.1.2-24 or later for the 7.x branch. Where ImageMagick is provided by an operating system or container base image, apply the vendor security update and rebuild/redeploy dependent images and services. If immediate upgrade is not possible, reduce exposure by preventing untrusted users from controlling filenames or symlinks in directories processed by ImageMagick, processing uploads in isolated non-shared temporary directories, running ImageMagick with the least-privileged service account, restricting filesystem access with containers/sandboxes/AppArmor/SELinux/seccomp where available, and reviewing ImageMagick policy.xml to minimize permitted coders and paths. Treat mitigations as temporary because the root issue is fixed in the patched versions.

How to confirm the fix worked

Confirm the installed ImageMagick version reports 6.9.13-48 or later, or 7.1.2-24 or later, using commands such as `magick -version`, `convert -version`, or package-manager inventory. Validate that all runtime locations are updated, including containers, build images, language bindings, statically bundled binaries, and application-specific vendor copies. Confirm package versions through OS package metadata and software composition analysis rather than relying only on a single system binary. For exposure validation, review whether any service allows untrusted users to upload archives, influence filenames, create symlinks, or control working directories used by ImageMagick. After patching, test representative workflows with symlink-based inputs to ensure files blocked by security policy cannot be read.

Typical attack path

1. Identify an application, batch job, or local workflow that invokes a vulnerable ImageMagick version.
2. Gain the ability to control an input filename, working directory, uploaded archive contents, or local symlink used during processing.
3. Create a symbolic link pointing to a sensitive local file that ImageMagick policy would normally block.
4. Submit a crafted filename/path that triggers incorrect parsing and bypasses the configured security policy.
5. Cause ImageMagick to read the symlink target.
6. Recover disclosed file contents from process output, transformed output, temporary files, logs, or application responses.

How to detect it

To assess prior exploitation, focus on places where ImageMagick processes untrusted files. Review application upload logs, archive extraction logs, web access logs, job-worker logs, EDR telemetry, auditd/file-integrity logs, container runtime logs, and process/file access telemetry for ImageMagick commands operating on unusual paths or symlinks. Look for `magick`, `convert`, `identify`, `mogrify`, or related delegate processes reading files outside expected image directories, especially `/etc/passwd`, `/etc/shadow`, SSH keys, cloud credentials, application configuration files, environment files, service-account tokens, and source/config directories. Investigate uploads or extracted archives containing symbolic links, filenames with traversal-like components, unusual URI-style prefixes, or paths resolving outside the processing workspace. Because exploitation may only produce file disclosure through normal application output, correlate suspicious ImageMagick invocations with subsequent downloads, error responses, generated files, or logs containing snippets of sensitive local files. If available, use Linux auditd/eBPF/EDR historical data to identify ImageMagick processes opening sensitive files that are not part of legitimate image-processing operations.

• process.name:magick AND file.type:symlink
• process.name:convert AND file.type:symlink
• process.name:identify AND file.type:symlink
• process.name:mogrify AND file.type:symlink
• magick -version
• convert -version
• identify -version
• mogrify -version
• /etc/passwd
• /etc/shadow
• /etc/hosts
• /etc/ssh/ssh_config
• /etc/ssh/sshd_config
• /root/.ssh/id_rsa
• /.ssh/id_rsa
• /.aws/credentials
• /.config/gcloud/application_default_credentials.json
• /.docker/config.json
• /.env
• /var/run/secrets/kubernetes.io/serviceaccount/token
• policy.xml
• delegates.xml
• type.xml
• MAGICK_CONFIGURE_PATH
• MAGICK_TMPDIR
• ImageMagick
• convert
• identify
• mogrify

What your security team should do

• Inventory all ImageMagick installations, including containers, CI/CD runners, media workers, CMS plugins, document conversion services, and language-library dependencies that shell out to ImageMagick.
• Prioritize upgrading internet-facing or multi-tenant image-processing services to ImageMagick 6.9.13-48/7.1.2-24 or later.
• Rebuild and redeploy container images and application bundles that include vulnerable ImageMagick binaries.
• Harden image-processing workflows so untrusted uploads are extracted and processed in isolated directories where attackers cannot plant symlinks to sensitive files.
• Run ImageMagick under a dedicated least-privileged account with minimal filesystem read permissions.
• Add monitoring for ImageMagick processes accessing sensitive files outside expected media-processing directories.
• Review logs and file-access telemetry for suspicious symlink-heavy uploads or unexpected reads of secrets, configuration files, SSH keys, cloud credentials, or system account files.
• Document temporary compensating controls and remove them only after patched versions are verified in production artifacts.