StyleSmuggler: Zero-Day-Backdoor kompromittiert vollständig gepatchte Magento-Shops

Angreifer nutzen eine ungepatchte Schwachstelle in Magento Open Source aus, um ohne Authentifizierung aus der Ferne Code auszuführen und eine persistente Linux-Backdoor zu installieren. Auch Adobe Commerce könnte betroffen sein, obwohl dieses Produkt bislang nicht abschließend getestet wurde.

Das niederländische E-Commerce-Sicherheitsunternehmen Sansec gab der Schwachstelle den Namen StyleSmuggler und machte die Kampagne am 5. September 2026 öffentlich, nachdem das Unternehmen ab dem 4. September Angriffe beobachtet hatte. Unabhängige Untersuchungen der Disrex Group bestätigten zwei erfolgreiche Kompromittierungen und einen Angriffsversuch.

Am 6. September hatte Adobe weder ein Advisory noch eine CVE-Kennung, einen Patch oder eine offizielle Übergangslösung veröffentlicht. Der Index der Sicherheitsbulletins für Adobe Commerce war seit dem 11. August nicht mehr aktualisiert worden.

Aktuelle Magento-Versionen nachweislich verwundbar

Sansec konnte die vollständige, nicht authentifizierte Angriffskette gegen saubere Installationen von Magento Open Source reproduzieren:

• 2.4.7
• 2.4.8
• 2.4.9

Nach Einschätzung des Unternehmens sind alle aktuellen Magento-Versionen betroffen, darunter auch 2.4.9.

Das erste identifizierte Opfer setzte Magento Open Source 2.4.6-p15 ein und hatte die Sicherheitsupdates von Adobe aus dem Juli und August 2026 installiert. Adobe bezeichnet die Patch-Stufe dieses Release-Zweigs als 2.4.6-2026-aug – die bislang aktuellste Version der 2.4.6-Reihe.

Disrex untersuchte unabhängig davon einen kompromittierten Shop mit 2.4.8 sowie einen weiteren mit 2.4.7-p2. Letzterer lag acht Patch-Stufen hinter dem damals aktuellen 2.4.7-p10. Der Patch-Stand war jedoch nicht ausschlaggebend: Beide Systeme wurden kompromittiert.

Der Produktumfang über Magento Open Source hinaus bleibt unklar. Sansec hat bislang keine erfolgreiche Reproduktion gegen Adobe Commerce oder Adobe Commerce on Cloud veröffentlicht. Auch Adobe hat nicht bestätigt, welche Versionen betroffen sind.

Die nächste planmäßige Sicherheitsveröffentlichung von Adobe ist für den 8. September vorgesehen. Ob dieses Update StyleSmuggler beheben wird, ist jedoch nicht bekannt. Bis zum 6. September war weder ein Eintrag in der CISA-Liste der bekannten, ausgenutzten Schwachstellen noch eine damit verbundene Frist zur Behebung gemeldet worden.

Manipulierte E-Mail-Darstellung schließt Angriffskette

StyleSmuggler nutzt zwei Stufen, um Daten, die bei regulären Magento-Vorgängen geschrieben wurden, in ausführbaren PHP-Code umzuwandeln.

Zunächst schleust der Angreifer PHP-Code in eine Datei ein, die Magento erstellen oder aktualisieren kann, etwa eine Datei mit Fehlerberichten. Anschließend löst er den standardmäßigen Magento-Versand der E-Mail „Payment Transaction Failed Reminder“ aus. Dadurch verarbeitet die Plattform beim Darstellen der Nachricht die manipulierte Datei.

Der Empfänger muss die E-Mail nicht öffnen. Der Code kann auch dann ausgeführt werden, wenn die Zustellung fehlschlägt.

Ein ungewöhnlicher Anstieg von Erinnerungen an fehlgeschlagene Zahlungen sollte daher untersucht werden. Allerdings können solche Nachrichten auch durch legitime abgelehnte Transaktionen entstehen.

Die Analyse des Quellcodes durch Disrex deutet darauf hin, dass eine eingeschleuste Direktive Magento-Klassen aufruft, die mit dem Compiler für die Dependency-Injection über die Kommandozeile verbunden sind. In der daraus entstehenden Sequenz wird ein vom Angreifer ausgewählter Dateipfad verwendet, der auf die kurz zuvor manipulierte Datei verweist.

Die Ermittler ordneten den mutmaßlichen Endpunkt drei Dateien unterhalb dieses Pfads zu:

setup/src/Magento/Setup/Module/Di/Code/

Sansec hat diese Interpretation nicht bestätigt. Disrex hat die vollständig zusammengesetzte schädliche Anfrage ebenfalls noch nicht veröffentlicht. Auch die vollständige Analyse der Angriffskette, des Droppers und des Implantats steht noch aus.

Nach erfolgreicher Codeausführung probiert ein PHP-Dropper nacheinander sechs Funktionen zur Prozesserzeugung aus. Anschließend lädt er die Backdoor herunter und startet sie.

Implantat tarnt sich als Linux-Kernel-Worker

Die Malware läuft im Hintergrund unter dem täuschenden Prozessnamen:

[kworker/u:8:0]

Diese Bezeichnung imitiert einen Linux-Kernel-Thread. Ein echter Kernel-Worker gehört jedoch root und verfügt über keinen residenten User-Space-Speicher. Ein Prozess mit dem Namen kworker in eckigen Klammern, der dem Benutzer eines Magento-Shops gehört und Speicher verbraucht, ist höchst verdächtig.

Das Implantat setzt seine Kommandozeile auf den Namen in eckigen Klammern. Eine Erkennung, die ausschließlich das Prozessfeld comm überprüft, kann es daher übersehen.

Der zentrale Speicherort der Payload liegt außerhalb des Webroots:

~/.local/share/.gvfsd/gvfsd-user

Disrex beschrieb die Payload als bereinigte, statisch gelinkte Rust-Datei mit einer Größe von etwa 1,9 MB. Sie liegt in Builds für x86-64 und arm64 vor. Die Persistenz wird über einen Cron-Eintrag hergestellt, der die Payload alle fünf Minuten neu startet:

*/5 * * * * exec <home>/.local/share/.gvfsd/gvfsd-user

Eine zweite Variante startet eine Payload aus /tmp/.kw_.

Statt die Crontab über den üblichen Befehl zu ersetzen, schreibt die Malware direkt in:

/var/spool/cron/crontabs/

So wird verhindert, dass in den Systemprotokollen das erwartete Ereignis zum Ersetzen der Crontab entsteht. In einem kompromittierten Shop enthielt dieselbe bösartige Zeile 1.728 Einträge. Das Implantat stellte sie innerhalb einer Sekunde nach ihrer Entfernung wieder her.

Weitere relevante Pfade sind:

~/.local/share/.gvfsd/.gvfsd_<8hex>.lock
/tmp/.gvfsd_<8hex>.lock
/tmp/.kw_<random><random>

Auf einem System unterschied sich die laufende ausführbare Datei von der auf dem Datenträger gespeicherten Payload. Einsatzkräfte sollten daher sowohl die Datei als auch die über folgenden Pfad eingebundene ausführbare Datei hashen:

/proc/<pid>/exe

Zwei Shops wurden vor dem Eintreffen der Schutzmaßnahmen kompromittiert

Disrex, das unter der Marke RexHosting Magento-Hosting anbietet, bestätigte zwei Kompromittierungen isolierter Kundenkonten.

Der erste betroffene Shop lief mit Magento Open Source 2.4.8 und wurde am 4. September um 23:10 UTC angegriffen. Sansec Shield war installiert, aktiviert und blockierte anderen schädlichen Datenverkehr. Spezifische Regeln für StyleSmuggler waren jedoch noch nicht verfügbar.

Ein zweiter Shop mit 2.4.7-p2 wurde erstmals am 5. September um 00:55 UTC angegriffen. Für diesen Shop war Shield nicht im Einsatz. Disrex nutzte die auf diesem System gesicherten Spuren für die technische Analyse und die Entwicklung von Regeln für den Webserver.

Beide Kompromittierungen ereigneten sich innerhalb eines Zeitraums von etwa acht Stunden zwischen den ersten beobachteten Aktivitäten der Kampagne und der Verfügbarkeit spezieller Schutzmaßnahmen.

Die betroffenen Konten hatten jeweils nur einen Site-Besitzer, keinen Sudo-Zugriff und keine Möglichkeit, in die Umgebungen anderer Kunden zu gelangen. Der schädliche Prozess lief unter dem unprivilegierten Benutzer des jeweiligen Shops. Disrex fand keine Hinweise auf laterale Bewegungen oder die Kompromittierung weiterer gehosteter Websites.

Beide Shops wurden noch am Tag ihrer Entdeckung isoliert – etwa elf beziehungsweise vierzehn Stunden nach dem ersten Kontakt. Sitzungen wurden ungültig gemacht und vorsorglich mit der Rotation der Zugangsdaten begonnen.

Die Ermittler fanden keine Hinweise auf:

• Gestohlene Daten
• Skimmer für Zahlungskartendaten
• Unbefugte Administratorkonten
• Backdoors in der Datenbank
• Laterale Bewegungen
• Die Kompromittierung benachbarter Websites

Wie viele Shops außerhalb dieser Untersuchungen betroffen sind, ist unbekannt.

Erkennung muss über das Dokumentenstammverzeichnis hinausgehen

Die erste Prüfroutine von Sansec durchsucht var/report/ nach:

X_TRACE_

Allein diese Suche reicht nicht aus. Bei den beiden von Disrex untersuchten Infektionen wurden stattdessen folgende Dateien manipuliert:

var/log/system.log

Auch der Marker änderte sich im Verlauf der Kampagne. Frühere Anfragen nutzten einen Header im Stil von X-TRACE-, gefolgt von zehn Hexadezimalzeichen. Spätere Anfragen ließen das Wort TRACE weg. Erkennungsregeln sollten daher die übergeordnete Struktur abdecken und nicht nur eine feste Zeichenfolge suchen.

Ein TypeError, bei dem array_merge() unmittelbar nach dem relevanten Include-Vorgang eine Ganzzahl erhält, weist auf eine erfolgreiche Ausnutzung hin. Das gilt jedoch nicht immer: Eine unauffälligere Variante gibt ein leeres Array zurück und hinterlässt keinen vergleichbaren Fehler.

Veröffentlichte SHA-256-Indikatoren sind:

e315687a1dfe61ef4a5a5642214db6d3b2b05d81391285eebc2af664641a26a7
8334b434fa3fe9f59cebe9609b11e0b1fd19d10212c45c705adec1902a1d06ef
251fabd50d7b18a8b5e1b3ef5d64e7198c17244778f6461fb1ab07f6169bf220

Netzwerkindikatoren sind:

247.cdnflare[.]xyz
99.84.67[.]186:443
88.216.72[.]181
5.181.86[.]133

Das Ausbleiben externer Datenübertragungen beweist nicht, dass ein System sauber ist. Ein Implantat stellte keine beobachtbare ausgehende Verbindung her, öffnete jedoch 28 Verbindungen zum Redis-Dienst des Shops auf Port 6379 und griff auf Magento-Sitzungsdaten zu.

Scans, die ausschließlich das Dokumentenstammverzeichnis prüfen, können ebenfalls fälschlicherweise Entwarnung geben. Bei einem kompromittierten Shop meldete der Scanner keinen Befund, obwohl das Home-Verzeichnis die Payload und 1.728 bösartige Cron-Einträge enthielt.

Was Magento-Betreiber jetzt tun sollten

Da kein offizieller Patch verfügbar ist, müssen Betreiber eine vorübergehende Verringerung der Angriffsfläche mit forensischen Prüfungen auf Kontoebene kombinieren.

Sansec empfiehlt, GraphQL bei Shops ohne Shield-Schutz vorübergehend zu deaktivieren. Für Headless- und Progressive-Web-Application-Storefronts, die auf GraphQL angewiesen sind, kann das undurchführbar sein. Klassische Bereitstellungen und Hyvä-Installationen benötigen GraphQL in der Regel nicht.

Disrex, ProxiBlue und Graycore haben inoffizielle Gegenmaßnahmen veröffentlicht. Der Quellcode-Patch von Disrex verhindert, dass drei Methoden des Dependency-Injection-Scanners über HTTP ausgeführt werden, und beschränkt sie auf die Ausführung über die Kommandozeile. Die composer-patches-Variante soll für Magento 2.4.6 bis 2.4.9 funktionieren und auch Composer-Bereitstellungen überstehen.

Administratoren sollten zunächst die Kompatibilität prüfen. Das Drittanbieterpaket mageplaza/module-admin-permissions ruft ClassesScanner.php über HTTP auf. Die Schutzmaßnahme kann daher dessen Administrationsoberfläche beeinträchtigen.

Veröffentlichte nginx- und Apache-Regeln blockieren Parameter, die bei den beobachteten Angriffen verwendet wurden – allerdings nur, wenn sie in der Query-String enthalten sind. Entsprechende Parameter in POST- oder JSON-Bodys erreichen PHP weiterhin. Diese Regeln stören die aktuelle Kampagne, beheben die Schwachstelle jedoch nicht.

Incident-Responder sollten das gesamte Hosting-Konto durchsuchen, einschließlich der Home-Verzeichnisse der Benutzer, /tmp, der Cron-Spool-Dateien, var/report/ und var/log/system.log. Laufende Prozesse sollten über /proc untersucht, Speicher- und Festplatten-Hashes verglichen, Magento-Sitzungen ungültig gemacht und Zugangsdaten geändert werden.

Ein sauberer Scan der Storefront reicht nicht aus. Ebenso wenig genügt es, die sichtbare Binärdatei zu entfernen, ohne den Prozess zu beenden und die persistente Cron-Ausführung zu beseitigen.