Seit dem 4. September 2026 läuft eine Angriffswelle gegen Magento Open Source und Adobe Commerce – und es gibt keinen Patch. Der Magento Zero-Day, den das niederländische Sicherheitsunternehmen Sansec entdeckt und „StyleSmuggler“ getauft hat, erlaubt Angreifern, ohne jede Anmeldung Code auf dem Server eines Shops auszuführen. Adobe hatte bis zum 6. September weder ein Advisory noch eine CVE-Nummer veröffentlicht. Ob das für den 8. September terminierte Sicherheitsrelease die Lücke schließt, war zum Redaktionsschluss offen.
Das Unangenehme an dieser Lücke: Der Patch-Stand schützt nicht. Sansec hat die vollständige 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 – dem aktuellsten Patchlevel, das Adobe für diese Versionslinie überhaupt anbietet, inklusive der Sicherheitsupdates von Juli und August 2026.
„Der Patch-Stand war hier irrelevant – das ist der Teil, den Händler hören müssen.“ – Disrex Group, die zwei kompromittierte Shops bereinigt hat
Wie funktioniert der StyleSmuggler-Angriff?
Der Angriff läuft in zwei Stufen. Zuerst schmuggeln die Angreifer PHP-Code in eine Datei, die Magento selbst schreibt – etwa ein Fehlerprotokoll unter var/report/ oder var/log/system.log. Danach lösen sie über die Plattform die Standard-E-Mail „Payment Transaction Failed Reminder“ aus. Beim Rendern dieser Nachricht führt Magento den eingeschleusten Code aus. Niemand muss die Mail öffnen; der Angriff funktioniert selbst dann, wenn der Versand scheitert.
Was danach auf dem Server landet, ist professionell gebaut: ein rund 1,9 MB großes Rust-Binary, das sich als Linux-Kernel-Thread [kworker/u:8:0] tarnt, außerhalb des Webroot im Home-Verzeichnis des Shop-Users liegt und sich per Cron alle fünf Minuten neu startet. In einem Fall trug das Implant denselben Cron-Eintrag 1.728 Mal ein – und schrieb ihn eine Sekunde nach dem Löschen wieder zurück. Auf einem der untersuchten Server las die Schadsoftware direkt die Magento-Sessions aus der Redis-Instanz aus.
Warum trifft es auch gepflegte Shops?
Weil die Lücke im Kern der Plattform steckt und kein Vendor-Fix existiert. Die Disrex Group, ein Magento-Hoster, der zwei der gehackten Shops betreut, dokumentierte beide Fälle: Shop A auf Version 2.4.8 mit aktivem Sansec-Shield-Modul, Shop B auf 2.4.7-p2. Beide wurden in einem Zeitfenster von rund acht Stunden kompromittiert – zwischen dem ersten beobachteten Angriff und dem Moment, in dem überhaupt eine Abwehr existierte.
Ein Frühwarnsignal kostet keinerlei Werkzeug: Erhält ein Shop-Betreiber eine „Payment Transaction Failed“-Mail, in der die Template-Variablen nicht aufgelöst wurden – rohe {{var ...}}-Tags, eine Kundenadresse auf einer .invalid-Domain, Bestellsumme null –, ist das Abgas eines Exploit-Versuchs. Genau so flog einer der beiden Disrex-Fälle auf. Zusätzlich empfiehlt Sansec, var/report/ und var/log/system.log nach Markern der Form X_TRACE_ zu durchsuchen; wer Sansecs Scanner eComscan einsetzt, sollte sicherstellen, dass der Scanpfad auch das Home-Verzeichnis oberhalb des Document Root erfasst – dort lag das Implant, nicht im Shop-Verzeichnis.
Was können Händler jetzt konkret tun?
Sansecs Übergangsempfehlung lautet: GraphQL temporär deaktivieren, bis Adobe einen Fix liefert. Das funktioniert für klassische Storefronts und Hyvä-Shops – Headless- und PWA-Frontends brauchen GraphQL dagegen zwingend und müssen anders absichern. Auf Server-Ebene nennt Disrex zwei Maßnahmen, die unabhängig von der Lücke wirken: proc_open in den PHP-disable_functions ergänzen (genau diese Funktion nutzte der Dropper) sowie /tmp, /var/tmp und /dev/shm mit noexec mounten.
Inoffizielle Absicherungen existieren bereits: Disrex und der Magento-Entwickler Lucas van Staden (ProxiBlue) haben unabhängig voneinander denselben Patch auf drei Scanner-Methoden in Magentos Dependency-Injection-Code veröffentlicht; Graycore stellt ein Hardening-Modul auf Packagist bereit. Alle drei betonen ausdrücklich: Das ist Härtung, kein Fix – und ein bereits kompromittierter Shop bleibt kompromittiert. Wer einen Fund meldet, dem raten die Forensiker, zuerst Beweise zu sichern, den Cron-Eintrag vor dem Prozess zu entfernen, nicht neu zu starten und anschließend den crypt/key in der env.php sowie sämtliche Admin-Passwörter und Payment-API-Keys zu rotieren.
Die nächsten Tage entscheiden, wie groß der Schaden wird. Adobes Sicherheitsrelease am 8. September ist der erste Termin, an dem ein offizieller Patch realistisch ist. Bis dahin gilt: StyleSmuggler ist kein Problem für nächste Woche, sondern für heute Nachmittag.