Ein vollständig gepatchter Shop ist keine Sicherheit mehr: Die erste bekannte Version einer aktuellen Angriffswelle auf Magento Open Source und Adobe Commerce lief auf Version 2.4.6-p15 – mit allen Sicherheitsupdates, die Adobe für diesen Release-Zweig überhaupt anbietet. Seit dem 4. September 2026 nutzen Angreifer eine Zero-Day-Lücke aus, die es erlaubt, ohne Login Schadcode auf dem Server auszuführen. Entdeckt hat die Lücke das niederländische Sicherheitsunternehmen Sansec, das ihr den Namen „StyleSmuggler“ gegeben hat und frühzeitig an die Öffentlichkeit ging, weil bereits Shops kompromittiert werden.
Wie funktioniert der Angriff auf Magento-Shops?
Der Angriff läuft in zwei Stufen. Zunächst schleusen die Angreifer PHP-Code in eine Datei ein, die Magento selbst schreibt – etwa ein Fehlerprotokoll unter var/log/ oder var/report/. Anschließend bringen sie Magento dazu, genau diese Datei auszuführen, indem sie die Standard-Mail „Payment Transaction Failed Reminder“ auslösen. Der Code läuft, während Magento die Nachricht rendert. Niemand muss die Mail öffnen, der Angriff funktioniert selbst dann, wenn der Versand scheitert.
Als Hintertür installiert die Schadsoftware einen Prozess, der sich als Linux-Kernel-Thread tarnt, und einen Cronjob, der ihn alle fünf Minuten neu startet. Der Magento-Hoster Disrex Group, der zwei der betroffenen Shops betreut, fand die Cron-Zeile in einem Fall 1.728-mal vor – das Implantat schrieb sie innerhalb einer Sekunde nach dem Löschen wieder zurück. Beide Shops wurden innerhalb von rund acht Stunden geknackt, bevor überhaupt eine Verteidigung existierte. Disrex‘ nüchternes Fazit: Der Patch-Status war irrelevant.
Welche Magento-Versionen sind betroffen?
Nach Sansecs Recherche alle – einschließlich 2.4.9, der jüngsten Version. Die vollständige Angriffskette ließ sich auf frischen Installationen von Magento Open Source 2.4.7, 2.4.8 und 2.4.9 reproduzieren. Adobe hatte bis zum 6. September weder ein Advisory noch eine CVE-Nummer oder einen Workaround veröffentlicht; die nächste planmäßige Sicherheitsveröffentlichung war für den 8. September terminiert. Ob sie die Lücke schließt, ist offen. Dass Adobe Commerce on Cloud betroffen ist, konnte bislang niemand bestätigen – ausschließen lässt es sich ebenso wenig.
Was können Shopbetreiber jetzt konkret tun?
Sansecs Sofortempfehlung lautet: GraphQL vorübergehend abschalten. Das ist für Headless- und PWA-Storefronts keine Option, für die meisten klassischen und Hyvä-Frontends dagegen unproblematisch. Daneben gibt es zwei serverseitige Maßnahmen, die unabhängig von der genauen Lücke wirken: die PHP-Funktion proc_open in disable_functions aufnehmen und die Verzeichnisse /tmp, /var/tmp und /dev/shm mit noexec einhängen, damit heruntergeladene Binärdateien nicht starten können. Inoffizielle Patches der Entwickler Disrex, ProxiBlue und Graycore existieren, greifen aber in Kerncode ein und werden bei jedem Composer-Update überschrieben – etwas für erfahrene Agenturen, nicht für den schnellen Selbstversuch.
Zur Erkennung eines bestehenden Befalls gelten diese Indikatoren:
- Prozess mit geklammertem Namen wie
[kworker/u:8:0], der einem Web-User statt root gehört - Datei
~/.local/share/.gvfsd/gvfsd-userim Home-Verzeichnis des Shop-Users - Cron-Eintrag, der diese Datei alle fünf Minuten ausführt
- Auffällige „Payment Transaction Failed Reminder“-Mails mit unaufgelösten
{{var}}-Platzhaltern
Genau so eine Mail – Adresse auf einer .invalid-Domain, Bestellsumme null, rohe Template-Variablen im Text – hat einen der bekannten Fälle überhaupt erst aufgedeckt. Sie kostet kein Tool und keine Agentur, nur Aufmerksamkeit. Wer ein Implantat findet, sollte alle Sessions invalidieren und sämtliche Zugangsdaten rotieren, inklusive des Crypt-Keys in app/etc/env.php und aller Payment-API-Schlüssel.
Bleibt die unbequeme Wahrheit dieser Woche: Wer Magento betreibt, trägt das Risiko, bis Adobe liefert. Wer GraphQL heute noch nicht abgeschaltet hat, sollte den Abend nicht mehr damit verbringen, diesen Artikel zu Ende zu lesen.