111.000 Magento- und Adobe-Commerce-Shops stehen seit dem 4. September 2026 unter Beschuss, und es gibt keinen Patch. Das niederländische Sicherheitsunternehmen Sansec hat die Zero-Day-Lücke entdeckt und auf den Namen „StyleSmuggler“ getauft. Angreifer führen Code auf dem Shop-Server aus, ohne sich anzumelden, und installieren eine persistente Hintertür.
Das Perfide daran: Der Patch-Stand spielt keine Rolle. Sansec hat die komplette Angriffskette auf sauberen Installationen der Versionen 2.4.7, 2.4.8 und 2.4.9 reproduziert. Das erste bekannte Opfer lief auf 2.4.6-p15, mit allen Sicherheitsupdates von Juli und August 2026, also dem aktuellsten Stand, den Adobe für diesen Release-Zweig anbietet. Die Disrex Group, die zwei kompromittierte Shops betreut, bringt es auf den Punkt: „Der Patch-Status war hier irrelevant, genau das müssen Händler hören.“
Warum Adobe Commerce-Händler bislang im Regen stehen
Adobe hat bis zum 6. September weder ein Advisory noch eine CVE-Nummer noch einen Workaround veröffentlicht. Das Security-Bulletin endet mit dem Update vom 11. August. Der nächste planmäßige Sicherheitsrelease ist für den 8. September terminiert, ob er diese Lücke schließt, ist offen.
Die Angriffe laufen seit dem 4. September. Beide von Disrex untersuchten Fälle wurden innerhalb eines Acht-Stunden-Fensters geknackt, in dem es noch keinerlei Abwehr gab. Als Sofortmaßnahme rät Sansec, GraphQL temporär abzuschalten. Das funktioniert für klassische Storefronts und die meisten Hyvä-Setups, Headless- und PWA-Shops sind auf GraphQL angewiesen und brauchen eine andere Lösung.
Wie erkenne ich, ob mein Magento-Shop infiziert ist?
Die Hintertür tarnt sich als Linux-Kernel-Thread namens [kworker/u:8:0], läuft aber unter dem unprivilegierten Shop-Nutzer statt unter root. Die Binärdatei liegt außerhalb des Webroots unter ~/.local/share/.gvfsd/gvfsd-user, ein Cron-Eintrag startet sie alle fünf Minuten neu. Auf einem der untersuchten Server fand Disrex diesen Cron-Eintrag 1.728-mal, das Implantat schrieb ihn eine Sekunde nach dem Löschen wieder.
Das einfachste Frühwarnsignal braucht kein Tooling: ungewöhnliche „Payment Transaction Failed Reminder“-E-Mails. Sieht der Betreiber eine solche Mail mit rohen {{var ...}}-Tags im Text, einer Kundenadresse auf einer .invalid-Domain und einer Bestellsumme von null, ist das Abgas eines Exploit-Versuchs. Genau so wurde einer der beiden Disrex-Fälle entdeckt, der Händler leitete die merkwürdige Mail weiter, eine Stunde später war das Implantat gefunden.
Wer eine fehlgeschlagene-Transaktions-Mail mit unaufgelösten Template-Variablen bekommt, sollte das nicht als kaputte Bestellung abtun, sondern als Alarm behandeln.
Handlungsdruck ohne offiziellen Fix
Bis Adobe liefert, bleibt der Markt auf sich gestellt. Neben Sansecs eComscan-Scanner haben Disrex und der Magento-Entwickler Lucas van Staden (ProxiBlue) unabhängig voneinander denselben inoffiziellen Patch veröffentlicht, ein Guard für drei Methoden in Magentos Dependency-Injection-Scannern. Zwei Parteien, die ohne Absprache auf identische Lösungen kommen: Das ist ein starkes Indiz, dass der Ansatz trägt. Vorsicht gilt dennoch, die Patches dürfen nicht kombiniert werden und werden bei jedem composer install überschrieben. Graycore hat zudem ein Hardening-Modul auf Packagist veröffentlicht, betont aber selbst: Härtung, kein Fix.
Zwei serverseitige Maßnahmen wirken unabhängig von der Lücke: proc_open in den PHP-disable_functions ergänzen und /tmp sowie /dev/shm mit noexec einhängen, damit heruntergeladene Binaries nicht starten können.
Wer einen Befall feststellt, muss Sessions flushen, den crypt/key in der env.php rotieren und sämtliche Admin-Passwörter und API-Schlüssel der Payment-Anbieter tauschen. Die kommenden Tage zeigen, ob Adobe am 8. September liefert. Bis dahin gilt: Prüfen schlägt hoffen.