Seit dem 4. September 2026 läuft eine Angriffswelle gegen Magento Open Source und Adobe Commerce – und es gibt keinen Patch. Die niederländische Sicherheitsfirma Sansec hat die Lücke am 5. September öffentlich gemacht, noch bevor Adobe reagiert hat. Ihr Name: StyleSmuggler. Die Schwachstelle erlaubt unauthentifizierte Remote Code Execution, also das Ausführen eigenen Codes auf dem Shop-Server, ohne Zugangsdaten, ohne Login. Betroffen sind nach Sansecs Angaben alle aktuellen Versionen, inklusive 2.4.9.
Der erste bestätigte Fall traf einen Shop auf Version 2.4.6-p15 – vollständig gepatcht, mit Adobes Juli- und August-Sicherheitsupdates. Wer glaubt, aktuelle Patches schützten, irrt diesmal. Sansec hat die komplette Angriffskette auf frischen Installationen der Versionen 2.4.7, 2.4.8 und 2.4.9 nachgestellt. Adobe hat bis Redaktionsschluss weder eine CVE-Nummer noch ein Advisory veröffentlicht; das letzte Commerce-Bulletin datiert vom 11. August (APSB26-92).
Wie funktioniert der StyleSmuggler-Angriff?
Die Attacke läuft in zwei Stufen. Zuerst schleust der Angreifer PHP-Code in eine Datei ein, die Magento selbst schreibt – etwa ein Fehler-Log oder einen Report. Anschließend löst er die Standard-Mail „Payment Transaction Failed Reminder“ aus. Magento rendert dabei die präparierte Datei und führt den Code aus. Niemand muss die Mail öffnen; der Angriff gelingt selbst, wenn der Versand scheitert.
Danach installiert sich eine persistente Backdoor. Der Schädling tarnt sich als Prozess namens [kworker/u:8:0] – ein Name, der eigentlich Linux-Kernel-Threads gehört –, legt seine Binärdatei außerhalb des Webroots ab und startet sich per Cronjob alle fünf Minuten neu. Die Agentur Disrex, die zwei kompromittierte Shops bereinigt hat, beobachtete zudem, wie das Implant die Magento-Sessions aus dem eigenen Redis-Speicher auslas.
Warum ausgerechnet eine kaputte Mail der wichtigste Warnhinweis ist?
Der vielleicht nützlichste Indikator braucht kein Security-Tool: eine „Payment Transaction Failed“-Mail mit unaufgelösten Template-Variablen, also sichtbaren {{var ...}}-Platzhaltern, einer Kundenadresse auf einer .invalid-Domain und einem Bestellwert von null. Genau so eine Mail leitete bei einem der beiden Disrex-Fälle der Shop-Betreiber weiter – und startete damit die Untersuchung, die das Implant binnen einer Stunde fand. Wer solche Mails in den letzten Tagen erhalten hat, sollte das als Incident behandeln, nicht als Zahlungsfehler.
Was Händler jetzt konkret tun können
Ein Vendor-Fix existiert nicht. Adobes nächster planmäßiger Security-Release ist für den 8. September terminiert – ob er StyleSmuggler abdeckt, ist offen. Bis dahin bleiben drei Ebenen:
- GraphQL temporär deaktivieren – Sansecs Sofortempfehlung. Achtung: Headless- und PWA-Storefronts brauchen GraphQL zwingend; klassische und Hyvä-Frontends meist nicht.
- Server härten:
proc_openin den PHP-disable_functionsergänzen und/tmp,/var/tmpsowie/dev/shmmitnoexecmounten. Beides wirkt unabhängig von der konkreten Lücke. - Inoffizielle Patches prüfen: Disrex und der Magento-Entwickler Lucas van Staden (ProxiBlue) haben unabhängig voneinander denselben Fix für die Dependency-Injection-Scanner veröffentlicht – ein starkes Indiz, dass er an der richtigen Stelle ansetzt. Auch Graycore hat ein Hardening-Modul auf Packagist bereitgestellt.
Wer einen Befall vermutet, sollte die Indikatoren prüfen: den Prozess [kworker/u:8:0] unter einem Nicht-Root-User, die Datei ~/.local/share/.gvfsd/gvfsd-user und Cron-Einträge, die alle fünf Minuten darauf zeigen. Sansecs Scanner eComscan erkennt das Implant – Vorsicht allerdings bei Scans, die nur das Document Root abdecken: Die Backdoor liegt eine Ebene höher.
Bleibt die unbequeme Wahrheit zum Schluss: Die beiden dokumentierten Fälle wurden innerhalb von acht Stunden kompromittiert – im Zeitfenster, in dem es noch keinerlei Abwehr gab. Händler, die jetzt nicht selbst nachsehen, verlassen sich auf ein Patch-Versprechen, das Adobe bislang nicht gegeben hat.