Eine kritische, noch ungepatchte Sicherheitslücke in Magento Open Source und Adobe Commerce wird derzeit aktiv ausgenutzt, um Webshops mit einer persistenten Backdoor zu infizieren. Angreifer können ohne Authentifizierung beliebigen Code auf dem Server ausführen – und das in allen aktuellen Versionen bis einschließlich 2.4.9. Die niederländische E-Commerce-Sicherheitsfirma Sansec entdeckte die Schwachstelle, taufte sie StyleSmuggler und meldete die ersten Angriffe für den 4. September. Da Adobe bislang weder einen Patch noch einen Workaround bereitgestellt hat, müssen Shopbetreiber sofort handeln.
StyleSmuggler: Eine Zero-Day-Lücke ohne Sicherheitsupdate
Sansec veröffentlichte die Informationen bewusst frühzeitig, weil die Angriffe bereits in vollem Gange sind. Adobe selbst hat bis zum 6. September weder eine Sicherheitswarnung noch eine CVE-Nummer oder einen Patch veröffentlicht; der letzte Eintrag im Security Bulletin Index datiert vom 11. August. Ein erfolgreicher Angriff gewährt dem Angreifer Codeausführung auf dem Shop-Server und installiert eine dauerhafte Backdoor. Sansec konnte die vollständige, nicht authentifizierte Angriffskette auf sauberen Magento-Open-Source-Installationen der Versionen 2.4.7, 2.4.8 und 2.4.9 reproduzieren. Das erste bekannte Opfer lief mit Version 2.4.6-p15, dem aktuellsten Patch-Level für diese Release-Linie, den Adobe selbst im August Bulletin als 2.4.6-2026-aug auflistet.
Die Angriffskette: Von der Log-Datei zur Root-Shell
Der Exploit erfolgt in zwei Stufen. Zunächst schleust der Angreifer PHP-Code in eine Datei ein, die Magento selbst anlegt – etwa beim Generieren eines Fehlerberichts in var/report/codecodecode oder über das Systemlog in var/log/system.logcodecodecode. Im zweiten Schritt wird Magento dazu gebracht, diese Datei auszuführen, und zwar über die Standard-E-Mail-Vorlage „Payment Transaction Failed Reminder“. Während Magento die Nachricht rendert, wird der injizierte Code ausgeführt – und das selbst dann, wenn die E-Mail-Zustellung fehlschlägt.
Die unabhängige Untersuchung durch die Magento-Hosting- und Entwicklungsfirma Disrex Group bestätigt diesen Ablauf. Disrex betreute zwei kompromittierte Shops und einen dritten, der angegriffen, aber nicht durchbrochen wurde. Die Lesart von Disrex besagt, dass eine Direktive im injizierten Text eine Kette von Magento-eigenen Klassen ansteuert, die schließlich in Code mündet, der für den Kommandozeilen-Dependency-Injection-Compiler existiert. Dieser inkludiert einen Dateipfad, den der Angreifer zuvor mit Schadcode befüllt hat.
Wichtig für die Forensik: Sansecs erster Suchindikator zielte auf die Datei var/report/codecodecode mit dem Marker X_TRACE_codecodecode. Disrex stellte jedoch fest, dass beide infizierten Shops über var/log/system.logcodecodecode vergiftet wurden – ein reiner Report-Check hätte die Infektion übersehen. Der Marker driftet zudem: Disrex sah X-TRACE-codecodecode mit zehn Hex-Zeichen am Morgen des 5. September; am Nachmittag tauchte ein ähnlicher Header ohne das Wort TRACE auf. Ein TypeError von array_merge()codecodecode mit einem Integer-Argument unmittelbar nach dem Include beweist den erfolgreichen Exploit – eine getarnte Variante hinterlässt jedoch keinen Log-Eintrag.
Die Backdoor: Getarnte Prozesse und persistente Cron-Jobs
Das finale Implantat tarnt sich als Linux-Kernel-Thread mit dem Namen [kworker/u:8:0]codecodecode, läuft aber unter dem unprivilegierten Website-Benutzer. Die Binärdatei (ca. 1,9 MB, statisch gelinktes Rust-Programm für x86-64 und arm64) liegt unter ~/.local/share/.gvfsd/gvfsd-usercodecodecode – oberhalb des Document Root. Ein Cron-Eintrag startet die Backdoor alle fünf Minuten neu, direkt in die Spool-Datei unter /var/spool/cron/crontabs/codecodecode geschrieben, sodass keine Änderung im Systemlog erscheint. Bei einem der Shops war die Zeile 1.728-mal vorhanden und wurde innerhalb einer Sekunde nach Löschung wiederhergestellt.
Ein bemerkenswerter Fund: Auf einem der beiden kompromittierten Shops baute das Implantat keine einzige ausgehende Verbindung auf. Stattdessen hielt es 28 Verbindungen zur eigenen Redis-Instanz auf Port 6379 und las den Magento-Session-Speicher aus. Keines der beiden erstellten Paket-Captures (jeweils über 200 MB) enthielt ein Paket an die von Sansec gelistete Download-Host- oder Command-and-Control-Adresse. Disrex bestätigte nach der Analyse, dass sich das Implantat auf den betroffenen Shop beschränkte, keine Lateralbewegung stattfand und kein weiterer Kunde auf der Platform infiziert wurde.
Folgende Indikatoren (Indicators of Compromise / IOCs) wurden von Sansec und Disrex veröffentlicht:
- Prozess:
[kworker/u:8:0]codecodecode unter einem Nicht-root-Benutzer - Datei:
~/.local/share/.gvfsd/gvfsd-usercodecodecode - Datei:
~/.local/share/.gvfsd/.gvfsd_<8hex>.lockcodecodecode - Datei:
/tmp/.gvfsd_<8hex>.lockcodecodecode - Datei:
/tmp/.kw_codecodecode - Cron:
*/5 * * * * exec <home>/.local/share/.gvfsd/gvfsd-usercodecodecode (alternative Variante mit/tmp/.kw_codecodecode) - SHA-256 (Sansec):
e315687a1dfe61ef4a5a5642214db6d3b2b05d81391285eebc2af664641a26a7codecodecode - SHA-256 (Festplatte, Disrex):
8334b434fa3fe9f59cebe9609b11e0b1fd19d10212c45c705adec1902a1d06efcodecodecode - SHA-256 (im Speicher, Disrex):
251fabd50d7b18a8b5e1b3ef5d64e7198c17244778f6461fb1ab07f6169bf220codecodecode - Domain:
247.cdnflare[.]xyzcodecodecode (Malware-Download-Host) - IPs:
99.84.67[.]186:443codecodecode (C2 via WebSocket/TLS),88.216.72[.]181codecodecode (Angreifer-Quelle),5.181.86[.]133codecodecode (Massenangriffe, Disrex)
Ein echter Kernel-Thread gehört root und hat keinen residenten Speicher; ein Name in eckigen Klammern unter dem Website-Benutzer mit realem Arbeitsspeicher ist das Implantat. Disrex empfiehlt, den Hash des laufenden Prozesses aus /proc/<PID>/execodecodecode sowie der Datei auf der Festplatte zu ziehen, da die Binärdatei im Speicher eines Shops eine andere Build-Version aufwies als die Datei auf Disk. Plötzliche Ausbrüche von „Payment Transaction Failed Reminder“-E-Mails sind ein Warnsignal, auch wenn legitime abgelehnte Zahlungen dieselbe Benachrichtigung auslösen.
Sofortmaßnahmen und Mitigationen bis zum offiziellen Patch
Da Adobe noch keinen Patch geliefert hat, stehen vorübergehende Optionen zur Verfügung. Sansec rät, GraphQL temporär zu deaktivieren, bis ein Fix erscheint. Headless- und PWA-Storefronts benötigen GraphQL allerdings – klassische und Hyvä-Storefronts kommen ohne aus. Der nächste geplante Sicherheits-Release von Adobe ist für den 8. September angesetzt; ob dieser die Lücke schließt, ist nicht bekannt.
Disrex hat nginx- und Apache-Regeln veröffentlicht, die Anfragen mit den Exploit-Parametern in der URL-Querystring blockieren. Allerdings umgehen POST- und JSON-Bodies diese Regel, da die Webserver nur den Querystring prüfen. Disrex betont, dass die Regeln lediglich die aktuelle Kampagne stoppen, nicht die Schwachstelle selbst.
Drei inoffizielle Patches stehen zur Verfügung: Disrex bietet einen Composer-Patch, der eine Prüfung in drei Dependency-Injection-Code-Scannern von Magento einfügt, sodass diese nur in der Kommandozeile laufen. Allerdings bricht eine Drittanbieter-Erweiterung (mageplaza/module-admin-permissions) auf, wenn ClassesScanner.phpcodecodecode blockiert wird. Ein GitHub-Nutzer (ProxiBlue) veröffentlichte denselben Guard unabhängig am 5. September. Die Firma Graycore veröffentlichte ein Magento-Modul, das drei Punkte abdichtet: den E-Mail-Template-Block-Directive, den Grid-Row-URL-Generator und PHP-Öffnungs-Tags in Web-API-Fehlerberichten. Der bereitgestellte Code zum Zeitpunkt der Veröffentlichung enthielt jedoch nur eine frühere Härtung gegen einen PayPal-GraphQL-Resolver; Graycore selbst warnt, dass es sich um Härtung, nicht um einen vollständigen Fix handelt.
Unabhängig von der Angriffskette lassen sich zwei serverseitige Einstellungen empfehlen: Das Deaktivieren von proc_opencodecodecode in der disable_functionscodecodecode-Liste von PHP und das Mounten von /tmpcodecodecode, /var/tmpcodecodecode und /dev/shmcodecodecode mit der Option noexeccodecodecode. In einem der von Disrex untersuchten Fälle waren vier der sechs vom Dropper probierten PHP-Funktionen deaktiviert, aber proc_opencodecodecode war aktiv, sodass der Dropper darüber das Implantat starten konnte.
Wichtige Einschränkung des eComscan-Scanners
Sansec empfiehlt seinen eigenen Scanner eComscan (Version 1.9.7) zur Erkennung. Disrex berichtet jedoch von einem Fehlalarm bei Store A: eComscan meldete den Shop als sauber, obwohl 1.728 Cron-Zeilen und die Backdoor aktiv waren. Ursache war der Scan-Pfad – der Scanner war nur auf das Document Root ausgerichtet, während das Implantat im Home-Verzeichnis eine Ebene darüber lag. Disrex hat den Scan-Pfad inzwischen erweitert.
Was betroffene Shopbetreiber jetzt tun sollten
Sollte eine Infektion festgestellt werden, empfiehlt Disrex eine klare Reihenfolge: Beweise sichern, dann den Cron-Eintrag entfernen, bevor der Prozess beendet wird (andernfalls stellt der Prozess den Cron selbst wieder her). Kein Reboot, da die Kopie unter /proccodecodecode möglicherweise die einzige Binärdatei ist. Kein composer installcodecodecode zur Bereinigung, weil dabei die Timestamps überschrieben werden, die Aufschluss über die Manipulation geben. Nach der Entfernung sollten der Session-Speicher geleert, der crypt/keycodecodecode in app/etc/env.phpcodecodecode rotiert sowie alle Admin-Passwörter, Zahlungsanbieter-API-Keys und Integrations-Credentials ausgetauscht werden.
Disrex betont ausdrücklich: Der Patch-Status des Shops war in beiden Fällen irrelevant – die verwundbare Stelle existiert unabhängig von Sicherheitsupdates, solange Adobe keine spezifische Korrektur liefert. Die Angreifer nutzen genau diese Lücke, bevor ein Patch existiert. Hosting-Provider wie Nexcess und Liquid Web haben vorsorgliche Maßnahmen angekündigt, bestätigen aber noch keine eigenen Kompromittierungen.
Fazit: Keine Entwarnung in Sicht
Die StyleSmuggler-Lücke ist eine der schwerwiegendsten Bedrohungen für Magento- und Adobe-Commerce-Shops der letzten Jahre. Die vollständige, nicht authentifizierte Codeausführung ohne Patch macht jedes System zum potenziellen Ziel. Der nächste geplante Sicherheitsrelease von Adobe am 8. September könnte einen Fix enthalten – ob das der Fall sein wird, ist offen. Bis dahin müssen Shopbetreiber auf die hier beschriebenen Mitigationen zurückgreifen, ihre Systeme akribisch auf die genannten Indikatoren prüfen und die Sicherheit ihrer gesamten Infrastruktur überdenken. Die Angreifer haben bereits bewiesen, dass sie innerhalb weniger Stunden ganze Shops übernehmen können – wer jetzt nicht handelt, riskiert nicht nur Datenverlust, sondern auch das Vertrauen seiner Kunden.
