In May 2016, a single malformed image file could hand an attacker a shell inside any web application that used ImageMagick to resize a thumbnail. The bug, catalogued as CVE-2016-3714 and nicknamed ImageTragick, let a crafted filename or embedded command execute through ImageMagick's delegate system — no authentication, no user interaction beyond a normal upload form. Six years later, CVE-2022-44268 proved the library still had teeth: a single PNG could pull arbitrary files, including SSH keys and environment secrets, out of a running container and hand them back to the attacker disguised as image metadata. That combination — no auth required, no user interaction beyond an ordinary upload — is exactly why securing Docker containers has to include the image-processing libraries baked into the base layer, not just the application code a team wrote itself. Both bugs share a root cause that Docker made worse: ImageMagick ships as a transitive dependency inside PHP, Ruby, Python, and Node.js image-processing stacks, and once it's baked into a base image, it rides along silently through every rebuild until someone goes looking for it.
What is the ImageMagick RCE vulnerability known as ImageTragick?
ImageTragick is the umbrella name for five vulnerabilities ImageMagick's own maintainers disclosed on May 3, 2016, the most severe of which, CVE-2016-3714, allows remote code execution with a CVSS score of 8.8. The flaw sits in ImageMagick's delegate feature, which shells out to external programs (curl, wget, ghostscript, and others) to handle formats the library doesn't natively support. Because ImageMagick determines file type by content ("magic bytes") rather than extension, an attacker can name a file exploit.jpg and still have it parsed as an MVG (Magick Vector Graphics) or MSL script. The now-famous public proof-of-concept payload was three lines:
push graphic-context
viewbox 0 0 640 480
image over 0,0 0,0 '|/usr/bin/id > /tmp/pwned'
When ImageMagick's image primitive sees a filename beginning with a pipe character, it passes everything after the pipe straight to the shell. The companion bugs — CVE-2016-3715 (arbitrary file deletion), CVE-2016-3716 (arbitrary file move), CVE-2016-3717 (local file read), and CVE-2016-3718 (server-side request forgery) — round out the set. ImageMagick shipped fixes in versions 6.9.3-10 and 7.0.1-1, released April 30, 2016, three days before the public advisory.
How does the ImageTragick exploit work inside a Docker container?
It works the same way it works on bare metal, except the container's isolation often becomes the only thing standing between the attacker and the host. A typical vulnerable flow: a Rails or PHP app running inside a container accepts a profile-picture upload, calls convert or identify (via RMagick, the imagick PHP extension, or Python's Wand) to generate a thumbnail, and ImageMagick's delegate mechanism executes the attacker's shell command as whatever user the container process runs as — frequently root in images built without a USER directive. From there, CVE-2016-3718's SSRF variant lets an attacker pivot the request to cloud metadata endpoints like 169.254.169.254, potentially harvesting IAM credentials from AWS, Azure, or GCP instance metadata services accessible from inside the container's network namespace. Because the exploit fires during routine image processing, it leaves no obvious log signature beyond a normal-looking upload request, which is why ImageTragick-class bugs are still found in incident postmortems years after patches shipped.
Why did CVE-2022-44268 make ImageMagick dangerous again in 2022?
CVE-2022-44268 is an arbitrary file read vulnerability, disclosed November 8, 2022, that leaks local file contents through PNG metadata rather than executing code directly. The bug was surfaced publicly after being reported against Metabase, an open-source business-intelligence tool commonly deployed in Docker, which lets users upload custom logo images that ImageMagick then processes. An attacker crafts a PNG whose tEXt chunk sets a profile field pointing at a local path — /etc/passwd, an SSH private key, or an application .env file. When the server-side ImageMagick call re-encodes that image (a routine step for thumbnailing or format normalization), it embeds the referenced file's contents into the output PNG's metadata. The attacker simply downloads the "processed" image and runs identify -verbose output.png to read the stolen file back out. Its sibling, CVE-2022-44267, causes a denial-of-service crash via a malformed PNG chunk. Both were fixed in ImageMagick 7.1.0-49 and 6.9.12-97, released the same month.
Which Docker images and libraries still ship a vulnerable ImageMagick?
Any image that pins ImageMagick below 6.9.12-97 or 7.1.0-49 is exposed to the 2022 file-read bug, and anything below 6.9.3-10 or 7.0.1-1 is exposed to the original 2016 RCE — and both versions still show up in production scans today. Base images built from Debian Buster or Alpine 3.9-era package snapshots, Dockerfiles that apt-get install imagemagick without a version pin, and CI pipelines that cache layers for months are the most common carriers. The vulnerability rarely appears as a direct dependency in a manifest file; it's almost always transitive, pulled in by a language wrapper: the imagick PHP extension, the rmagick or mini_magick Ruby gems, Python's Wand, or the Node.js imagemagick and gm packages. Because these wrappers call the system-installed convert/identify binaries rather than bundling their own, a scanner that only inspects package.json, Gemfile.lock, or requirements.txt will miss the vulnerable binary entirely — it has to inspect the OS package layer of the image itself.
How do you detect and remediate ImageMagick RCE risk when securing Docker containers?
Detection requires scanning the actual OS-level packages inside your container images, not just application dependency manifests, since ImageMagick is installed via apt, apk, or yum in the base layer. Remediation has two parts. First, upgrade: move to ImageMagick 7.1.0-49/6.9.12-97 or later to close both the 2016 and 2022 issues, and rebuild images rather than patching a running container. Second, harden policy.xml regardless of version, since defense-in-depth here has repeatedly prevented variants of these bugs: explicitly disable the coders most abused by delegate attacks with rules like <policy domain="coder" rights="none" pattern="{MVG,MSL,EPHEMERAL,URL,HTTPS,TEXT,SVG,PS,PDF}" />. Pair that with running the container as a non-root user, restricting egress from image-processing services so an SSRF attempt can't reach 169.254.169.254, and validating uploaded file types against actual content rather than trusting client-supplied extensions.
How Safeguard Helps
Safeguard's SBOM generation and ingest pipeline catches ImageMagick at the OS-package layer inside your Docker images — not just in package.json or Gemfile.lock — so transitive installs via apt/apk don't slip through unnoticed. Reachability analysis then confirms whether your application code actually invokes a vulnerable delegate path (image upload, PDF conversion, thumbnail generation) before your team burns a sprint patching a binary nothing calls. Griffin AI cross-references that reachability data against known ImageTragick and CVE-2022-44268 exploitation patterns to prioritize the handful of container images genuinely at risk out of hundreds in a registry. When a fix is warranted, Safeguard opens an auto-fix PR that bumps the pinned ImageMagick version and tightens policy.xml in the same Dockerfile change, so remediation ships as a reviewable diff instead of a manual scramble.