StyleSmuggler-Zero-Day verschafft Angreifern Fernzugriff auf gepatchte Magento-Shops

Eine bislang unbekannte Schwachstelle namens StyleSmuggler wird derzeit aktiv gegen Magento- und Adobe-Commerce-Shops ausgenutzt – auch gegen Systeme mit aktuellen Sicherheitsupdates.

Der Angriff ermöglicht nicht authentifizierte Remote-Code-Ausführung über die Template-Verarbeitung und die GraphQL-bezogene Verarbeitung von Magento. Bei erfolgreichen Eindringversuchen wurden eine Linux-Backdoor auf Rust-Basis und in einigen Fällen eine versteckte PHP-Webshell installiert.

SecurityAffairs veröffentlichte am 7. September 2026 Einzelheiten zu der Kampagne und schrieb die technische Untersuchung Sansec zu. Die ersten beobachteten Exploit-Versuche fanden am 4. September statt.

Bisher wurden weder eine CVE-Kennung noch ein CVSS-Score oder eine offizielle Adobe-Schweregradbewertung veröffentlicht. Auch ist nicht bekannt, ob die Schwachstelle im Katalog der bekannten ausgenutzten Schwachstellen der US Cybersecurity and Infrastructure Security Agency geführt wird.

Aktuelle und vollständig gepatchte Shops bleiben gefährdet

StyleSmuggler betrifft Magento Open Source und Adobe Commerce. Eine autoritative Übersicht der betroffenen Versionen liegt bislang jedoch nicht vor.

Sansec konnte den Exploit auf sauberen Installationen reproduzieren und identifizierte ein erstes Opfer, auf dem Magento 2.4.6-p15 mit den Sicherheitsupdates von Juli und August 2026 lief. Als betroffen wurden ausdrücklich folgende aktuelle Versionen von Magento Open Source identifiziert:

• Magento Open Source 2.4.7
• Magento Open Source 2.4.8
• Magento Open Source 2.4.9

In einem separaten Bericht werden alle Magento- und Adobe-Commerce-Versionen als gefährdet bezeichnet. Bis Adobe einen Sicherheitshinweis veröffentlicht, sollten Administratoren nicht davon ausgehen, dass eine ältere, neuere oder vollständig gepatchte Version sicher ist.

Das Ausmaß der Gefährdung ist beträchtlich. Magento läuft Berichten zufolge auf mehr als 160.000 Websites, darunter etwa 14.000 der weltweit eine Million meistbesuchten Websites. Ein Angriff auf den Server kann Angreifern Zugriff auf Kundendaten, Administratorkennwörter, API-Tokens, Geheimnisse von Zahlungsdienstleistern, Datenbankpasswörter und Cloud-Zugriffsschlüssel verschaffen.

Adobe bereitete Berichten zufolge einen Fix vor. Eine für den 8. September geplante Sicherheitsveröffentlichung wurde erwartet; es war jedoch nicht bekannt, ob die Behebung von StyleSmuggler darin enthalten sein würde.

Eine Benachrichtigung über eine fehlgeschlagene Zahlung löst die Ausführung aus

Der Exploit zielt auf die Template-Rendering-Pipeline von Magento. Über die Verarbeitung im Zusammenhang mit der Eigenschaft styles und GraphQL wird PHP eingeschleust. Dabei werden Kontrollen umgangen, die gefährliche Template-Inhalte abweisen sollen.

Die beobachtete Angriffskette umfasst zwei wesentliche Schritte. Zunächst erstellt oder manipuliert ein nicht authentifizierter Angreifer einen Magento-Datensatz, der schädliches PHP enthält. Ein nachgewiesener Angriffsweg besteht darin, einen Bericht über eine fehlgeschlagene Zahlung zu erzeugen.

Magento rendert anschließend seine standardmäßige Benachrichtigung Payment Transaction Failed Reminder. Während dieses Vorgangs wertet die Plattform die manipulierten Inhalte aus und führt das eingebettete PHP auf dem Server aus.

Kein Kunde und kein Administrator muss dazu einen Anhang öffnen oder einem Link folgen. Der Exploit kann auch dann erfolgreich sein, wenn die Benachrichtigungs-E-Mail nie zugestellt wird, da die Ausführung während des serverseitigen Rendering-Prozesses von Magento erfolgt.

Ein unerklärlicher Anstieg bei Benachrichtigungen über fehlgeschlagene Zahlungen kann daher auf eine Ausnutzung hindeuten. Er ist jedoch kein eindeutiger Beleg, da auch legitime Zahlungsfehler denselben Benachrichtigungstyp erzeugen.

Eine Änderung des Magento-Session-Backends blockiert den Angriff nicht zuverlässig. Bei einem Vorfall scheiterte ein Versuch über die Session-Speicherung. Acht Sekunden später wechselte derselbe Akteur zu einer Datei, die über die Funktion für benutzerdefinierte Optionen von Magento hochgeladen wurde, und erreichte eine Codeausführung.

Der schnelle Wechsel deutet darauf hin, dass die Angreifer ihre Methoden zur Übermittlung der Nutzlast aktiv anpassen. Abwehrmaßnahmen, die sich auf einen einzigen Speicherort für Nutzdaten oder ein bestimmtes Proof-of-Concept-Muster stützen, dürften daher nicht ausreichen.

Rust-Backdoor tarnt sich mit Linux-Prozessnamen und NTP-Datenverkehr

Bei erfolgreichen Angriffen wurde ein kompaktes Linux-Implantat auf Rust-Basis eingesetzt. Die Malware läuft im Hintergrund, verbindet sich mit einer von Angreifern kontrollierten Infrastruktur und wartet auf Befehle.

Als die Ergebnisse veröffentlicht wurden, waren noch keine nachfolgenden Befehle des Implantats beobachtet worden. Ein Host mit dieser Backdoor muss dennoch als kompromittiert behandelt werden, da der Angreifer weiterhin über die Möglichkeit zur Ausführung entfernter Befehle verfügt.

Die Malware wechselte zwischen den Samples ihre Tarnung als Prozess:

• Ein frühes Sample erschien als [kworker/u:8:0]
• Eine am 6. September beobachtete Variante verwendete fc-cache
• Ein am 7. September beobachtetes Sample verwendete chronyd

Diese Namen imitieren einen Kernel-Worker, das Linux-Programm zur Erstellung des Font-Caches und einen verbreiteten Daemon zur Zeitsynchronisierung. Anhand des Prozessnamens allein lässt sich das Implantat nicht von legitimer Software unterscheiden.

Die Variante mit fc-cache kopierte sich nach ~/.cache/fontconfig/fc-cache, erstellte eine PID-Sperrdatei und richtete Persistenz über cron ein. Der geplante Task startete das Implantat alle 30 Minuten erneut.

Andere Builds verwendeten eine abweichende Persistenz. Eine chronyd-Variante nutzte cron, während eine andere sich selbst neu startete, ohne einen sichtbaren Cron-Eintrag zu hinterlassen. Ein leeres Crontab ist daher kein Beleg dafür, dass ein Server sauber ist.

Frühere Samples kommunizierten über TLS und WebSockets. Neuere Versionen tarnen den Command-and-Control-Datenverkehr als Network-Time-Protocol-Aktivität, indem sie UDP-Pakete an Port 123 senden.

Das Implantat löst ntp.timesync.to alle 60 Sekunden auf und überträgt 48 Byte große Pakete, die wie Antworten von NTP-Servern aussehen. Nur die ersten vier Byte folgen einer konventionellen NTP-ähnlichen Struktur. Die übrigen Daten können die Implantat-ID, den Hostnamen, den Benutzernamen, die Betriebssystemversion, die Betriebszeit, die Speicher- und Festplattenauslastung, den Root-Status und die Malware-Version enthalten.

Die beobachteten Domains waren am 7. September der IP-Adresse 185.157.160.251 zugeordnet. Die Backdoor kann außerdem ipify, icanhazip, ident.me und ipinfo.io abfragen, um die öffentliche IP-Adresse des Servers zu ermitteln.

Vor dem Beaconing prüft sie den Linux-Wert TracerPid auf Hinweise auf Debugging oder Tracing. Wird eine Überwachung erkannt, installiert sich die Malware dennoch, unterdrückt aber ihre Netzwerkkommunikation.

Ein zweiter Akteur versteckte eine Webshell in Verzeichnissen für Bild-Caches

Die Ermittler fanden außerdem Hinweise auf einen offenbar unabhängigen Akteur, der kompromittierte Shops ausnutzte. Dieser Akteur installierte einen kleinen PHP-Dropper, der eine Webshell in den Produktbild-Cache von Magento schrieb.

Die Shell wurde unter Verzeichnisnamen platziert, die wie Hashes aussahen, und konnte dadurch wie automatisch erzeugte Cache-Inhalte wirken. Normalerweise gab sie eine unauffällige 404-Antwort zurück.

Die schädliche Funktion wurde erst aktiv, wenn eine Anfrage den korrekten Header X-Cache-Token enthielt. Anschließend führte die Shell PHP aus, das über einen POST-Parameter übermittelt wurde.

Vor der Installation der Shell kontaktierte der Dropper:

457cfa2fb7p5.daf892t5qau4og8pi4cghbc6fhm1dim3u.oast.site

Die Adresse gehört zu einem öffentlichen Out-of-Band-Testdienst, der häufig verwendet wird, um die erfolgreiche Ausführung eingeschleusten Codes zu bestätigen. Die wiederhergestellte Nutzlast stammte aus einem Magento-Request-Header Store, während die PHP-Tags in dem von Magento gespeicherten Datensatz weiterhin JSON-escaped waren.

Das Entfernen eines sichtbaren Rust-Prozesses reicht daher nicht aus. Ein betroffener Server kann außerdem manipulierte Datensätze, vergiftete Templates, hochgeladene Nutzlasten, Persistenz über cron und PHP-Shells enthalten, die in beschreibbaren Medien- oder Cache-Verzeichnissen versteckt sind.

Diese Indikatoren sollten Verteidiger jetzt untersuchen

Magento-Betreiber sollten Telemetriedaten aus Anwendung, Host, DNS und Netzwerk miteinander abgleichen, statt sich auf einen einzelnen Indikator zu verlassen. Vorrangig sollten sie prüfen:

• Anstiege bei Payment Transaction Failed Reminder-Benachrichtigungen
• Unerwartete PHP- oder JSON-escaped-PHP-Tags in Magento-Datensätzen
• Veränderte Templates, verdächtige Berichte und ungewöhnliche Uploads über benutzerdefinierte Optionen
• Prozesse mit den Namen [kworker/u:8:0], fc-cache oder chronyd, die aus ungewöhnlichen Pfaden ausgeführt werden
• Die Datei ~/.cache/fontconfig/fc-cache
• Cron-Jobs, die alle 30 Minuten verdächtige Binärdateien ausführen
• Wiederholte Meldungen crontab: command not allowed im Zusammenhang mit Konten wie www-data
• PHP-Dateien unter pub/media, insbesondere in Verzeichnissen für den Produktbild-Cache
• Anfragen mit dem Header X-Cache-Token
• DNS-Anfragen für ntp.timesync.to
• Verbindungen zu oder von 185.157.160.251
• Unerwarteten ausgehenden UDP/123-Datenverkehr oder 48 Byte große NTP-ähnliche Pakete
• Die genannte OAST-Domain in Magento-, Webserver-, DNS- oder Proxy-Logs

Besonders verdächtig ist ein scheinbar legitimer chronyd-Prozess, der jede Minute neun schnelle NTP-Server-Mode-Pakete erzeugt. Administratoren sollten solchen Datenverkehr mit den konfigurierten Zeitquellen des Hosts und dem üblichen Synchronisierungsmuster vergleichen.

Indikatoren können sich schnell ändern. Die Kampagne hat zwischen dem 6. und 7. September bereits Prozessnamen, Persistenztechniken und Angriffswege gewechselt.

GraphQL nach Möglichkeit deaktivieren und Funde als Kompromittierung behandeln

Bis Adobe einen offiziellen Fix veröffentlicht und Administratoren ihn einspielen, empfiehlt Sansec, GraphQL vorübergehend zu deaktivieren, sofern dies betrieblich möglich ist. Dadurch können Funktionen des Shops oder externe Integrationen beeinträchtigt werden. Unternehmen sollten die Auswirkungen daher testen und kompensierende Schutzmaßnahmen in Betracht ziehen, wenn GraphQL nicht deaktiviert werden kann.

Teams sollten beschreibbare Magento-Verzeichnisse, Cron-Spool-Dateien, Prozessbäume, Authentifizierungs-Logs, Webserver-Protokolle, DNS-Verläufe und ausgehenden UDP/123-Datenverkehr untersuchen. Jeder StyleSmuggler-Indikator sollte zur Isolierung des Hosts und zur forensischen Sicherung führen.

Die Incident Response sollte außerdem den Austausch von Magento-Administratorkennwörtern, API-Tokens, Datenbankzugangsdaten, Geheimnissen von Zahlungsdienstleistern und Cloud-Schlüsseln umfassen, auf die vom Server aus zugegriffen werden kann. Vor der Wiederherstellung des Betriebs sollten die Einsatzteams nach sekundären Webshells, schädlichen Datensätzen, veränderten Templates, hochgeladenen ausführbaren Dateien und Persistenzmechanismen außerhalb von cron suchen.

Ein sauberer Patch-Status schützt nicht vor dieser Kampagne. Solange keine verifizierte Behebung verfügbar ist, sollten exponierte Magento- und Adobe-Commerce-Systeme als potenziell gefährdet überwacht werden. Systeme mit entsprechenden Indikatoren sollten dagegen als bereits kompromittiert behandelt werden.