StyleSmuggler: Magento-Zero-Day ohne Patch, aktiv ausgenutzt

Am 4. September 2026 um 22:20 UTC wurde der erste bestätigte StyleSmuggler-Angriff auf einen Magento-Shop registriert. Das niederländische Security-Team von Sansec hat die Kampagne 20 Minuten später erkannt, am 5. September öffentlich gemacht und dem Angriff seinen Namen gegeben. Was daran ungewöhnlich ist: Das erste bestätigte Opfer lief auf Magento 2.4.6-p15 mit allen Security-Patches bis August 2026 — dem höchstmöglichen Patchstand dieser Release-Linie.

Stand heute, 7. September 2026, gibt es keinen offiziellen Adobe-Patch, keine CVE-Nummer und kein Advisory. Der nächste reguläre Bulletin-Termin ist der 8. September. Dieser Artikel fasst zusammen, was technisch passiert, wie du prüfst, ob dein Shop betroffen ist, und welche Sofortmaßnahmen heute sinnvoll sind.

Was StyleSmuggler technisch macht

StyleSmuggler ist eine unauthentifizierte Remote-Code-Execution-Kette — der Angreifer braucht keinen Account, keinen Admin-Zugang, keine Interaktion eines Nutzers. Die Kette läuft in zwei Stufen:

Stufe 1 — Injection. Der Angreifer schleust PHP-Code über die styles-Properties in Magentos Template-Verarbeitung ein und umgeht damit die vorhandenen Schutzmechanismen. Magento schreibt den Payload anschließend selbst in eine Datei, auf die die Applikation Zugriff hat — typischerweise unter var/report/ oder in var/log/system.log.

Stufe 2 — Execution. Der eingeschleuste Code kommt zur Ausführung, wenn Magento eine Benachrichtigung über eine fehlgeschlagene Zahlung rendert. Die Angreifer triggern dafür gezielt den Standard-Mechanismus „Payment Transaction Failed Reminder”. Ausgeführt wird beim Rendern — die Mail muss dafür gar nicht zugestellt werden. Beteiligt sind Methoden der Dependency-Injection-Scanner, die vergiftete Dateien per include bzw. require_once einbinden; PHP parst und führt dann alles aus, was an PHP-Code darin steht.

Das Ergebnis ist eine persistente Backdoor auf dem Shop-Server. Sansec beschreibt das Implant als in Rust kompilierte, gestrippte Binary (rund 1,9 MB, x86-64 und arm64), die sich als Linux-Kernel-Thread tarnt, sich alle 60 Sekunden mit System-Telemetrie beim C2-Server meldet — und ihren Cron-Eintrag innerhalb von Sekunden nach dem Löschen wieder neu setzt.

Betroffene Versionen und Zeitleiste

Version	Status
2.4.6-p15 (inkl. Juli-/August-Patches 2026)	Erstes bestätigtes Opfer
2.4.7	Angriffskette von Sansec auf Clean-Install reproduziert
2.4.8	Angriffskette von Sansec auf Clean-Install reproduziert
2.4.9 (aktuelles Release)	Angriffskette von Sansec auf Clean-Install reproduziert

Sansec spricht von „allen aktuellen Versionen” von Magento Open Source und Adobe Commerce. Die praktische Konsequenz: Ein aktueller Patchstand ist hier keine Verteidigung. Wer sein Magento sauber aktuell hält — was sonst die richtige Antwort ist, siehe End-of-Life-Aktionsplan für 2.4.6 — ist bei StyleSmuggler genauso exponiert.

Zeitleiste der Kampagne

Zeitpunkt (UTC)	Ereignis
04.09.2026, 22:20	Erster bestätigter StyleSmuggler-Angriff
04.09.2026, 22:40	Sansec erkennt die Kampagne
04.09.2026, 23:10	Kompromittierung eines von Disrex betreuten Servers
05.09.2026, 07:15	Erste Erkennungsregeln verfügbar
05.09.2026, 13:51	Kompromittierung bei der Incident Response bestätigt
06.09.2026	Neue Persistenz-Variante identifiziert (fc-cache)
08.09.2026	Nächster planmäßiger Adobe-Security-Bulletin-Termin

Entscheidend ist das Fenster dazwischen: Zwischen dem ersten Angriff und den ersten verfügbaren Erkennungsregeln lagen rund neun Stunden. In dieser Zeit half kein Signatur-basierter Schutz — die zweite dokumentierte Kompromittierung erfolgte bereits 50 Minuten nach dem Kampagnenstart.

Schritt 1: Prüfen, ob dein Shop kompromittiert ist

Bevor du irgendetwas absicherst, kläre den Ist-Zustand. Auf einem bereits übernommenen System hat Cleanup Vorrang vor jeder Mitigation.

Indikatoren einer Kompromittierung

Von Sansec und Disrex veröffentlichte Indikatoren (Stand 7. September 2026):

Prozesse

• [kworker/u:8:0] unter einem Nicht-root-User (erste Variante)
• fc-cache (Variante vom 6. September)

Dateien und Persistenz

• ~/.local/share/.gvfsd/gvfsd-user plus zugehörige Lock-Dateien
• ~/.cache/fontconfig/fc-cache (fc-cache-Variante)
• Verzeichnisse /tmp/.kw_* und /tmp/.fc_*
• Cron-Einträge mit */5 * * * * bzw. 13,43 * * * *

Netzwerk

• Malware-Hosts: 247.cdnflare[.]xyz, 209.141.43[.]95
• C2: 99.84.67[.]186:443 (WebSocket über TLS), ntp.timesync[.]to:123 (als NTP getarnt), windwsecurity[.]run:443
• POST-Requests auf /graphql?styles[....]=
• Gefälschter User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36

Der unterschätzte Frühindikator: fehlerhaft gerenderte „Payment Transaction Failed”-Mails mit unaufgelösten Template-Variablen. Wenn im Shop-Postfach plötzlich kaputte Zahlungs-Fehlermails auftauchen, ist das für Händler das nützlichste Frühwarnsignal überhaupt — und es erreicht dich nicht über einen Scanner, sondern im Posteingang.

Die Checks

Alle Checks laufen read-only und dauern zusammen keine zwei Minuten.

# Implant-Prozess: eckige Klammern im Namen, aber nicht root
ps -eo pid,user,rss,args --no-headers | awk '$4 ~ /^\[/ && $2 != "root"'

# Persistenz
crontab -l | grep -i gvfsd
ls -la ~/.local/share/.gvfsd/ /tmp/.kw_* /tmp/.gvfsd-* 2>/dev/null

# Stufe 1: vergiftete Dateien im Magento-Root
grep -rl 'X_TRACE_\|<?php' var/report/ var/log/ 2>/dev/null

# Stufe 2: Angriffsversuche im Access-Log
grep -acE 'styles(\[|%5B)|generatorClass|with_resolved|cdnflare' /pfad/zum/access.log

Auf Shared Hosting bzw. Servern mit mehreren Shops zusätzlich als root:

find /home /root /tmp /var/tmp /dev/shm \
  \( -name 'gvfsd-user' -o -name '.gvfsd_*.lock' -o -name '.kw_*' \) 2>/dev/null

Treffer bei den Prozess-, Cron- oder Datei-Checks bedeuten aktive Kompromittierung. Treffer nur im Access-Log bedeuten Angriffsversuche — prüfe dann besonders sorgfältig, ob Stufe 1 erfolgreich war.

Schritt 2: Sofortmaßnahmen

Es gibt keinen offiziellen Fix. Alles Folgende ist Notfall-Mitigation — sie schließt bekannte Angriffspfade, ersetzt aber keinen Adobe-Patch und entfernt keine bestehende Infektion.

2a — Query-String-Regeln am Webserver

Disrex hat nginx- und Apache-Snippets veröffentlicht, die die beobachteten Request-Muster blocken. Für nginx, innerhalb des jeweiligen server { }-Blocks:

# Der Gadget-Parameter. Keine legitime Magento-Route nutzt ihn.
if ($query_string ~* "styles(\[|%5B)")                                  { return 444; }

# Object-Injection-Driver aus der beobachteten Kette
if ($query_string ~* "(generatorClass|with_resolved)")                  { return 444; }

# Magento-Template-Direktiven im Query-String
if ($query_string ~* "(\{\{|%7B%7B)\s*(block|config|trans|var|depend)") { return 444; }

# Rohes PHP-Open-Tag im Query-String
if ($query_string ~* "(<\?|%3C%3F)")                                    { return 444; }

# Rohes PHP-Open-Tag im User-Agent
if ($http_user_agent ~* "<\?(php|=)")                                   { return 444; }

Vor dem Reload immer nginx -t. Wichtige Einschränkung: Diese Regeln inspizieren ausschließlich den Query-String. Ein Angreifer, der dieselben Parameter in den POST-Body verschiebt, läuft daran vorbei. Das ist eine Bremse, kein Schloss.

2b — DI-Scanner-Methoden auf CLI beschränken

Der wirksamere Eingriff: Die drei Dependency-Injection-Scanner-Methoden, die als include/require_once-Sink dienen, per PHP_SAPI !== 'cli'-Guard für Web-Requests sperren. Betroffen sind:

• ArrayScanner::collectEntities()
• XmlInterceptorScanner::_handleControllerClassName()
• ClassesScanner::includeClass()

setup:di:compile funktioniert damit weiter. Vorher prüfen, ob Drittanbieter-Module diese Klassen über HTTP aufrufen — das kommt vor und würde durch den Guard brechen. Vergleichbare inoffizielle Patches gibt es von ProxiBlue, Disrex und Graycore.

2c — Angriffsfläche und Ausführungsumgebung verkleinern

• GraphQL temporär deaktivieren, bis ein offizieller Patch vorliegt. Für Shops mit Agentic-Commerce-Anbindung oder PWA-Frontend ist das ein echter Funktionsverlust — die Abwägung muss bewusst getroffen werden.
• proc_open in disable_functions der PHP-Konfiguration aufnehmen.
• /tmp, /var/tmp und /dev/shm mit noexec mounten.
• Magento-Zugangsdaten und Keys rotieren, wenn verdächtige Prozesse gefunden wurden. Das Implant hat in dokumentierten Fällen auf den lokalen Redis-Dienst zugegriffen.

Was die Incident-Response-Praxis zeigt

Disrex hat zwei kompromittierte Magento-Open-Source-Shops bearbeitet und die Analyse öffentlich gemacht. Beide waren binnen 11 bis 14 Stunden eingedämmt. In beiden Fällen fanden sich keine Datenexfiltration, keine Payment-Skimmer und keine angelegten Admin-Accounts — die Angreifer haben es (bisher) auf dauerhaften Serverzugriff abgesehen, nicht auf Kartendaten. Über beide Vorfälle hinweg wurden 26 verschiedene Angreifer-Quelladressen identifiziert.

Bemerkenswert: Einer der beiden Shops lief auf 2.4.8 und hatte kommerziellen Malware-Schutz aktiv — die Kompromittierung erfolgte trotzdem, weil sie vor der Veröffentlichung der ersten Erkennungsregeln stattfand. Bei einem Zero-Day dieser Art gilt eben: Signatur-basierter Schutz beginnt erst zu greifen, wenn jemand die Signatur geschrieben hat.

Wie viele Shops insgesamt betroffen sind, hat Sansec nicht veröffentlicht. Kursierende Zahlen in Sekundärquellen sind nicht belegt — verlass dich auf deine eigenen Log-Checks, nicht auf Schätzungen.

Unsere Einschätzung

Drei Punkte, die wir Kunden diese Woche so kommunizieren:

Erstens: Patchstand ist hier kein Argument. Der übliche Reflex — „wir sind auf dem aktuellsten Stand, uns betrifft das nicht” — trägt bei StyleSmuggler nicht. Prüfe die Indikatoren, unabhängig von der Version.

Zweitens: Log-Retention entscheidet über die Aufklärbarkeit. Wenn deine Access-Logs nur sieben Tage vorgehalten werden, ist das Zeitfenster ab dem 4. September bald weg. Sichere die Logs jetzt weg, bevor die Rotation sie überschreibt — auch wenn du aktuell keinen Treffer hast.

Drittens: Mitigation ist keine Bereinigung. Wenn das Implant läuft, hilft kein Webserver-Regelwerk mehr. Dann gilt der volle Incident-Response-Ablauf: isolieren, Image sichern, Credentials rotieren, aus verifiziert sauberer Quelle neu aufsetzen. Alles andere ist Symptombehandlung an einem Prozess, der sich alle fünf Minuten selbst neu startet.

Wir aktualisieren diesen Artikel, sobald Adobe ein Advisory, eine CVE-Nummer oder einen Patch veröffentlicht.

Was du als Nächstes tun kannst

Wenn du unsicher bist, ob dein Shop betroffen ist, oder die Sofortmaßnahmen nicht selbst ausrollen willst: Wir prüfen deine Umgebung auf die bekannten Indikatoren, sichern die Logs und bringen die Mitigation kontrolliert auf Staging und Produktion — im Rahmen von Magento-Sicherheit und laufender Betreuung. Kontakt: Security-Check anfragen oder per Mail an office@copex.io.

Verwandte Themen aus unserem Blog: Wie sicher ist mein Magento-Onlineshop?, Sicheres Update- und Patch-Management für Magento, Häufigste Sicherheitslücken bei Magento-Shops, Magento 2.4.6 End-of-Life: Aktionsplan.

Quellen / Weiterlesen

• Sansec — StyleSmuggler: Magento and Adobe Commerce 0-day RCE under active attack
• Disrex — StyleSmuggler Magento Zero-Day (Incident-Response-Analyse)
• disrex-group/stylesmuggler-mitigation — Notfall-Mitigation auf GitHub
• The Hacker News — Unpatched Magento and Adobe Commerce Zero-Day Exploited to Backdoor Online Stores
• Adobe — Security Bulletins and Advisories für Magento / Adobe Commerce