ImageMagick CVE-2026-46557: a missing depth check in the fx operation — and why image processing in the CMS is the underrated attack surface

TL;DR — 90 seconds

Affected?

ImageMagick before the current patch level (fx operation) and the .NET binding Magick.NET < 14.13.1. Practically relevant wherever ImageMagick/GraphicsMagick processes images in the background — TYPO3 image processing, shop thumbnails, upload pipelines.

Risk?

Denial of service through uncontrolled recursion (stack overflow) on a crafted fx argument (CWE-674). No RCE, no data exfiltration.

Immediate action?

Bring ImageMagick to the current patch level, Magick.NET to ≥ 14.13.1. Additionally harden policy.xml and disable coders/operations you do not need.

Recommendation?

The German Mittelstand and enterprises alike: patch within the week; if you process uploads directly through ImageMagick, prioritise the policy.xml hardening — it works against the whole class, not just this one CVE.

Criticality?

medium — DoS, local vector, no active exploit; hardening rather than a fire alarm.

What is the problem?

ImageMagick’s fx operation is a small expression interpreter: it lets you evaluate a mathematical formula per pixel (for colour transformations, say). CVE-2026-46557 lies in the fact that this evaluation had no sufficient depth check — a crafted argument could drive the recursion so deep that the program stack overflows (CWE-674, uncontrolled recursion). The result is a crash of the processing process: a denial of service, no memory write and no control-flow hijack.

The CVSS 3.1 vector is AV:L/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H — base score 6.2 (Moderate/Medium). What matters is the AV:L (local attack vector) and the pure A:H (availability only): it is exploited through a controlled fx argument, not automatically through every uploaded image. Exactly for that reason I do not treat this CVE as a one-off emergency but as an occasion to look at the class — because the fx flaw does not stand alone. In 2026 ImageMagick accumulated several decoder/parser flaws triggered through file inputs, for instance CVE-2026-25985 (a crafted SVG file drives ImageMagick to a ~674 GB memory request, out-of-memory abort, CVSS 7.5, fix 7.1.2-15 / 6.9.13-40). These file-driven variants are the truly dangerous kind in a CMS upload pipeline.

Who is affected?

Any pipeline that sends untrusted uploads directly through ImageMagick (editorial uploads, customer uploads in the shop, avatar/media imports) aggravates the situation — above all with regard to the file-driven sibling CVEs. A restrictive policy.xml that cleanly sets dangerous coders (e.g. MSL, URL, partly SVG) and resource limits mitigates it.

Impact

For CVE-2026-46557 in isolation, the impact is a process crash: where ImageMagick runs synchronously in a web request, that means an availability hit for that processing path; where it runs in a worker, an aborted job. No RCE, no data exfiltration — the severity stays moderate, the local vector limits the reach.

The honest read belongs right next to it: the operational relevance of this one CVE is low for a typical CMS, because fx expressions rarely come from user input. The relevance of the topic is high, because the same library is attackable through file decoders that very much are fed from uploads (SVG OOM, XBM heap overflow, MSL use-after-free in the 2026 series). Whoever runs image processing unhardened has a DoS and memory attack surface reachable with every upload — regardless of whether the fx flaw in particular is ever triggered.

Mitigation and immediate steps

Now: update ImageMagick / Magick.NET

# Check the version
magick -version    # or convert -version (older builds)

# Debian/Ubuntu
sudo apt update && sudo apt install --only-upgrade imagemagick

# Wolfi / Alpine (rebuild container images instead of patching)
apk info imagemagick    # check the level, rebuild the image with the current version

# Magick.NET (.NET)
dotnet add package Magick.NET-Q16-AnyCPU --version 14.13.1

Harden policy.xml (works against the whole class)

<!-- /etc/ImageMagick-7/policy.xml (path depends on distribution/version) -->
<policymap>
  <policy domain="resource" name="memory" value="256MiB"/>
  <policy domain="resource" name="map" value="512MiB"/>
  <policy domain="resource" name="width" value="16KP"/>
  <policy domain="resource" name="height" value="16KP"/>
  <policy domain="resource" name="list-length" value="128"/>
  <policy domain="coder" rights="none" pattern="MSL"/>
  <policy domain="coder" rights="none" pattern="URL"/>
  <policy domain="coder" rights="none" pattern="HTTPS"/>
  <policy domain="coder" rights="none" pattern="MVG"/>
  <policy domain="coder" rights="none" pattern="SVG"/>
  <policy domain="path" rights="none" pattern="@*"/>
</policymap>

Decouple processing

# Run image processing not synchronously in the web request, but in a worker with a timeout/resource cap.
# That way a decoder crash becomes a failed job instead of a web DoS.

Detection and verification

Version and policy in the estate

# Which version, and which image backend does TYPO3 use?
magick -version | head -n2
# TYPO3: Install Tool / LocalConfiguration -> GFX 'processor' (ImageMagick vs GraphicsMagick) + processor_path

# Does the policy.xml actually take effect?
magick -list policy | sed -n '1,40p'
magick svg:/dev/null /tmp/out.png 2>&1 | grep -i 'not authorized' && echo "SVG blocked - ok"

Crash/resource anomalies

# Aborted processing processes / OOM killer in the kernel log
journalctl -k | grep -iE 'imagemagick|convert|oom-killer'
# Check worker logs for recurring aborts on particular uploads

Verify after the patch

magick -version | head -n1     # current patch level?
magick -list policy | grep -iE 'memory|svg|msl|url'   # limits/blocks active?

Operator recommendation

Operational decision block:

• Harden now if: untrusted uploads (editorial, shop customers) run directly through ImageMagick — prioritise the policy.xml hardening, update in the same move.
• Maintenance window this week if: ImageMagick only processes curated, self-generated images — schedule the update, add the hardening as a standard.
• Low pressure if: already on the current patch level with a restrictive policy.xml active — then just verify and document.

Mittelstand

The biggest lever is not the single patch but the policy.xml: resource limits plus disabling unneeded coders (MSL, URL, MVG, possibly SVG) harden against the whole decoder class — including the next CVE in this series. On top of that, bring ImageMagick/Magick.NET up to date and check which backend TYPO3 actually uses (ImageMagick vs. GraphicsMagick).

Enterprise / Kubernetes

Move image processing into a resource-limited worker (CPU/memory limits, timeout), rebuild images with the current ImageMagick version and pin by digest; version the policy.xml as part of the image rather than maintaining it ad hoc on the host.

What I did concretely

In my own platform I process editorial and media uploads, and I have long treated the image-processing layer as what it is: a parser for untrusted input. CVE-2026-46557 was not an emergency for me — I do not feed the fx operation from user input — but a good occasion to check the policy.xml again against the file-driven sibling CVEs. Concretely: resource limits confirmed, unneeded coders blocked, SVG only via a hardened path, and processing runs in a worker with a timeout anyway, so a decoder crash stays a failed job rather than a web DoS.

The lesson is an architectural statement: a library that decodes uploads belongs fenced in, not just patched. The patch closes the one fx recursion; the policy.xml and the worker decoupling close the class — and the next CVE in this series will, in my experience, surely come.

Conclusion

CVE-2026-46557 is, on its own, a moderate DoS flaw with a local vector — no reason for haste, but a good occasion to ask the right question: how well fenced in is my image-processing layer? ImageMagick and GraphicsMagick are the quiet library that decodes untrusted uploads in TYPO3 and shops, and 2026 has shown that decoder flaws surface there regularly. The single patch is mandatory; the policy.xml hardening and the worker decoupling are the real answer, because they work against the class rather than just this one CVE.

Sources

• GitHub Security Advisory GHSA-rcr6-g7jc-f57g — “ImageMagick: Stack overflow in fx operation” (CVE-2026-46557) (primary source; GHSA published 17 May 2026, NVD published 10 June 2026; CVSS 6.2, CWE-674)
• NVD — CVE-2026-46557
• NVD — CVE-2026-25985 (SVG memory exhaustion, ~674 GB OOM, 7.5; fix 7.1.2-15 / 6.9.13-40) (file-driven sibling CVE, context)
• ImageMagick — Security Policy / policy.xml (documentation)
• TYPO3 — GFX/image-processing configuration (documentation)