ImageMagick CVE-2026-46557: Ein fehlender Tiefen-Check in der fx-Operation — und warum die Bildverarbeitung im CMS die unterschätzte Angriffsfläche ist

TL;DR — 90 Sekunden

Betroffen?

ImageMagick vor dem aktuellen Patch-Stand (fx-Operation) sowie die .NET-Bindung Magick.NET < 14.13.1. Praktisch relevant überall dort, wo ImageMagick/GraphicsMagick im Hintergrund Bilder verarbeitet — TYPO3-Bildbearbeitung, Shop-Thumbnails, Upload-Pipelines.

Risiko?

Denial-of-Service durch unkontrollierte Rekursion (Stack-Overflow) bei einem präparierten fx-Argument (CWE-674). Kein RCE, kein Datenabfluss.

Sofortmaßnahme?

ImageMagick auf den aktuellen Patch-Stand bringen, Magick.NET auf ≥ 14.13.1. Zusätzlich die policy.xml härten und nicht benötigte Coder/Operationen abschalten.

Empfehlung?

Mittelstand und Enterprise: im Wochenfenster patchen; wer Uploads direkt durch ImageMagick verarbeitet, die policy.xml-Härtung priorisieren — sie wirkt gegen die ganze Klasse, nicht nur gegen diese eine CVE.

Kritikalität?

medium — DoS, lokaler Vektor, kein aktiver Exploit; Härtung statt Feueralarm.

Was ist das Problem?

Die fx-Operation von ImageMagick ist ein kleiner Ausdrucks-Interpreter: Sie erlaubt es, pro Pixel eine mathematische Formel auszuwerten (etwa für Farbtransformationen). CVE-2026-46557 liegt darin, dass diese Auswertung keinen ausreichenden Tiefen-Check hatte — ein präpariertes Argument konnte die Rekursion so tief treiben, dass der Programm-Stack überläuft (CWE-674, Uncontrolled Recursion). Das Ergebnis ist ein Absturz des verarbeitenden Prozesses: ein Denial-of-Service, kein Speicher-Schreibzugriff und kein Codefluss-Hijack.

Der CVSS-3.1-Vektor lautet AV:L/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H — Basis-Score 6.2 (Moderate/Medium). Wichtig ist das AV:L (lokaler Angriffsvektor) und das reine A:H (nur Verfügbarkeit): Ausgenutzt wird über ein kontrolliertes fx-Argument, nicht automatisch über jedes hochgeladene Bild. Genau deshalb behandeln wir diese CVE nicht als Einzel-Notfall, sondern als Anlass, die Klasse anzusehen — denn die fx-Lücke steht nicht allein. ImageMagick hat 2026 mehrere Decoder-/Parser-Lücken gesammelt, die über Datei-Eingaben getriggert werden, etwa CVE-2026-25985 (eine präparierte SVG-Datei treibt ImageMagick zu einer ~674-GB-Speicheranforderung, Out-of-Memory-Abbruch, CVSS 7.5, Fix 7.1.2-15 / 6.9.13-40). Diese dateigetriebenen Varianten sind in einer CMS-Upload-Pipeline die eigentlich gefährliche Spielart.

Wer ist betroffen?

Verschärfend wirkt jede Pipeline, die nicht vertrauenswürdige Uploads direkt durch ImageMagick schickt (Redaktions-Uploads, Kunden-Uploads im Shop, Avatar-/Medien-Importe) — vor allem im Hinblick auf die dateigetriebenen Schwester-CVEs. Entschärfend wirkt eine restriktive policy.xml, die gefährliche Coder (z. B. MSL, URL, teils SVG) und Ressourcen-Limits sauber setzt.

Auswirkungen

Für CVE-2026-46557 isoliert ist die Auswirkung ein Prozess-Absturz: Wo ImageMagick synchron in einem Web-Request läuft, bedeutet das einen Verfügbarkeits-Hit für diesen Verarbeitungspfad; wo es in einem Worker läuft, einen abgebrochenen Job. Kein RCE, kein Datenabfluss — die Schwere bleibt moderat, der lokale Vektor begrenzt die Reichweite.

Die ehrliche Einordnung gehört direkt daneben: Die operative Relevanz dieser einen CVE ist für ein typisches CMS gering, weil fx-Ausdrücke selten aus Nutzereingaben stammen. Die Relevanz des Themas ist hoch, weil dieselbe Bibliothek über Datei-Decoder angreifbar ist, die sehr wohl aus Uploads gespeist werden (SVG-OOM, XBM-Heap-Overflow, MSL-Use-after-free in der 2026er-Serie). Wer die Bildverarbeitung ungehärtet betreibt, hat eine DoS- und Speicher-Angriffsfläche, die mit jedem Upload erreichbar ist — unabhängig davon, ob ausgerechnet die fx-Lücke je getriggert wird.

Mitigation und Sofortmaßnahmen

Sofort: ImageMagick / Magick.NET aktualisieren

# Version prüfen
magick -version    # bzw. convert -version (ältere Builds)

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

# Wolfi / Alpine (Container-Images neu bauen statt patchen)
apk info imagemagick    # Stand prüfen, Image mit aktueller Version neu bauen

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

policy.xml härten (wirkt gegen die ganze Klasse)

<!-- /etc/ImageMagick-7/policy.xml (Pfad je nach 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>

Verarbeitung entkoppeln

# Bildverarbeitung nicht synchron im Web-Request, sondern im Worker mit Timeout/Ressourcen-Cap.
# So wird ein Decoder-Absturz zum fehlgeschlagenen Job statt zum Web-DoS.

Detection und Prüfung

Version und Policy im Bestand

# Welche Version, und welches Bildbackend nutzt TYPO3?
magick -version | head -n2
# TYPO3: Install-Tool / LocalConfiguration -> GFX 'processor' (ImageMagick vs GraphicsMagick) + processor_path

# Greift die policy.xml wirklich?
magick -list policy | sed -n '1,40p'
magick svg:/dev/null /tmp/out.png 2>&1 | grep -i 'not authorized' && echo "SVG gesperrt – ok"

Crash-/Ressourcen-Auffälligkeiten

# Abgebrochene Verarbeitungs-Prozesse / OOM-Killer im Kernel-Log
journalctl -k | grep -iE 'imagemagick|convert|oom-killer'
# Worker-Logs auf wiederkehrende Abbrüche bei bestimmten Uploads prüfen

Nach dem Patch verifizieren

magick -version | head -n1     # aktueller Patch-Stand?
magick -list policy | grep -iE 'memory|svg|msl|url'   # Limits/Sperren aktiv?

Betreiberempfehlung

Operational Decision Block:

• Jetzt härten, wenn: nicht vertrauenswürdige Uploads (Redaktion, Shop-Kunden) direkt durch ImageMagick laufen — policy.xml-Härtung priorisiert, Update im selben Zug.
• Wartungsfenster diese Woche, wenn: ImageMagick nur kuratierte, selbst erzeugte Bilder verarbeitet — Update einplanen, Härtung als Standard nachziehen.
• Geringer Druck, wenn: bereits aktueller Patch-Stand und restriktive policy.xml aktiv — dann nur verifizieren und dokumentieren.

Mittelstand

Der größte Hebel ist nicht der einzelne Patch, sondern die policy.xml: Ressourcen-Limits plus Abschalten nicht benötigter Coder (MSL, URL, MVG, ggf. SVG) härten gegen die ganze Decoder-Klasse — auch gegen die nächste CVE dieser Serie. Dazu ImageMagick/Magick.NET auf Stand bringen und prüfen, welches Backend TYPO3 tatsächlich nutzt (ImageMagick vs. GraphicsMagick).

Enterprise / Kubernetes

Bildverarbeitung in einen ressourcenbegrenzten Worker auslagern (CPU/Memory-Limits, Timeout), Images mit aktueller ImageMagick-Version neu bauen und über Digest pinnen; die policy.xml als Teil des Images versionieren, nicht ad hoc auf dem Host pflegen.

Was wir bei Moselwal konkret getan haben

Wir verarbeiten in unserer eigenen Plattform Redaktions- und Medien-Uploads und behandeln die Bildverarbeitungs-Schicht seit Längerem als das, was sie ist: ein Parser für nicht vertrauenswürdige Eingaben. CVE-2026-46557 war für uns kein Notfall — die fx-Operation füttern wir nicht aus Nutzereingaben —, aber ein guter Anlass, die policy.xml erneut gegen die dateigetriebenen Schwester-CVEs zu prüfen. Konkret: Ressourcen-Limits bestätigt, nicht benötigte Coder gesperrt, SVG nur über einen gehärteten Pfad, und die Verarbeitung läuft ohnehin im Worker mit Timeout, sodass ein Decoder-Absturz ein fehlgeschlagener Job bleibt statt ein Web-DoS.

Die Lehre ist eine Architektur-Aussage: Eine Bibliothek, die Uploads decodiert, gehört eingehegt, nicht nur gepatcht. Der Patch schließt die eine fx-Rekursion; die policy.xml und die Worker-Entkopplung schließen die Klasse — und die nächste CVE dieser Serie kommt erfahrungsgemäß bestimmt.

Fazit

CVE-2026-46557 ist für sich genommen eine moderate DoS-Lücke mit lokalem Vektor — kein Grund zur Hektik, aber ein guter Anlass, die richtige Frage zu stellen: Wie gut ist meine Bildverarbeitungs-Schicht eingehegt? ImageMagick und GraphicsMagick sind die stille Bibliothek, die in TYPO3 und Shops nicht vertrauenswürdige Uploads decodiert, und 2026 hat gezeigt, dass dort regelmäßig Decoder-Lücken auftauchen. Der einzelne Patch ist Pflicht; die policy.xml-Härtung und die Worker-Entkopplung sind die eigentliche Antwort, weil sie gegen die Klasse wirken statt nur gegen diese eine CVE.

Quellen

• GitHub Security Advisory GHSA-rcr6-g7jc-f57g — „ImageMagick: Stack overflow in fx operation“ (CVE-2026-46557) (Primärquelle; GHSA publ. 17.05.2026, NVD-Veröffentlichung 10.06.2026; CVSS 6.2, CWE-674)
• NVD — CVE-2026-46557
• NVD — CVE-2026-25985 (SVG-Speicher-Erschöpfung, ~674 GB OOM, 7.5; Fix 7.1.2-15 / 6.9.13-40) (dateigetriebene Schwester-CVE, Kontext)
• ImageMagick — Security Policy / policy.xml (Dokumentation)
• TYPO3 — GFX/Image-Processing-Konfiguration (Dokumentation)