StyleSmuggler: Magento-0-Day wird aktiv ausgenutzt. Was du jetzt tun musst

Seit dem 4. September werden Magento- und Adobe-Commerce-Shops über eine bislang unbekannte Lücke angegriffen. Sansec hat sie StyleSmuggler getauft. Ein Angreifer braucht weder Login noch Admin-Zugang und bekommt am Ende die Möglichkeit, beliebigen Code auf dem Shop-Server auszuführen. Betroffen sind alle aktuellen Versionen, auch ein vollständig gepatchtes 2.4.9. Von Adobe gibt es bis heute (7. September) weder Advisory noch CVE noch Patch. Auf unseren Servern hat der 360°-Rundumschutz die Angriffsversuche auf geschützten Accounts bereits blockiert, bevor Sansec die Lücke veröffentlicht hat. Wer Magento betreibt, sollte nicht auf Adobe warten, sondern jetzt handeln.

Was ist StyleSmuggler?

StyleSmuggler ist eine RCE-Lücke Remote Code Execution: ein Angreifer bringt den Server dazu, fremden Code auszuführen, ohne selbst Zugang zu haben. in Magentos Template-System. Der Name kommt von der styles-Eigenschaft, über die sich Code an den bestehenden Schutzmechanismen vorbeischmuggeln lässt. Der Angriff läuft in zwei Stufen:

1. Einschleusen. Der Angreifer platziert PHP-Code in einer Datei, die Magento im normalen Betrieb selbst schreibt, zum Beispiel in einem Fehlerbericht unter var/report/. Beobachtet wurden dafür POST-Requests auf /graphql?styles[...]=.
2. Ausführen. Anschließend löst er gezielt eine fehlgeschlagene Zahlung aus. Magento generiert daraufhin die Standard-E-Mail „Payment Transaction Failed Reminder”. Beim Rendern dieser Mail wird der eingeschleuste Code ausgeführt.

Niemand muss die Mail öffnen. Der Code läuft, sobald Magento die Nachricht zusammenbaut. Es spielt auch keine Rolle, ob die Mail tatsächlich zugestellt wird: Der Angriff funktioniert auch dann, wenn der Versand scheitert. Das ist der Punkt, den du dir merken solltest: Keine E-Mail im Postfach heißt nicht, dass dein Shop sicher ist.

Nach der Analyse von Disrex führt eine Direktive im eingeschleusten Text über eine Kette von Magento-eigenen Klassen in Code, der eigentlich nur dem Kommandozeilen-Compiler für die Dependency Injection dient. Dieser Code bindet am Ende genau die Datei ein, die der Angreifer zuvor vergiftet hat. Magento bringt die Werkzeuge für den Angriff also selbst mit.

Wer ist betroffen?

Sansec hat die vollständige Kette ohne Authentifizierung auf frisch installierten Magento Open Source 2.4.7, 2.4.8 und 2.4.9 nachgestellt. Das erste bekannte Opfer lief auf 2.4.6-p15 mit allen Patches aus Juli und August 2026, der Patch-Status war sauber. Adobe Commerce ist genauso betroffen wie Magento Open Source, das gilt nach aktuellem Stand auch für Adobe Commerce on Cloud.

Im Klartext: Ein aktuelles Patch-Level schützt nicht. Genau das unterscheidet StyleSmuggler von den meisten Magento-Lücken der letzten Jahre. Bei SessionReaper oder CosmicSting gab es zum Zeitpunkt der Angriffswelle einen Patch, den viele Shops nur nicht eingespielt hatten. Diesmal gibt es nichts, was man einspielen könnte.

Adobes nächstes reguläres Security-Bulletin ist für den 8. September angekündigt. Ob es StyleSmuggler abdeckt, ist offen. Adobes Bulletin-Index zeigt bis heute keinen Eintrag nach dem 11. August.

Woran du einen Angriff erkennst

Nach erfolgreicher Ausnutzung startet ein Hintergrundprozess. Es handelt sich um ein kleines, statisch gelinktes Rust-Programm von etwa 1,9 MB, das es für x86-64 und ARM64 gibt. Es tarnt sich als Kernel-Thread [kworker/u:8:0] oder, in den Builds seit dem 6. September, als fc-cache. Der Prozess verbindet sich mit einem Command-and-Control-Server und wartet auf Befehle. Die Kommunikation ist als NTP-Zeitabgleich getarnt: UDP-Pakete an Port 123, an Hosts mit Namen wie ntp.timesync.to. So etwas fällt in den wenigsten Firewalls auf.

Der Backdoor sichert sich per Cron ab. Die kworker-Variante startet sich alle fünf Minuten neu, die fc-cache-Variante zweimal pro Stunde (13,43 * * * *). Disrex berichtet von einem Shop mit 1.728 identischen Cron-Zeilen, die der Prozess innerhalb von Sekunden wieder anlegte, nachdem sie gelöscht worden waren. Zum Zeitpunkt der Veröffentlichung erkannte laut VirusTotal keine andere Sicherheitsfirma als Sansec die Datei als schädlich.

Diese vier Befehle, ausgeführt als der Benutzer, unter dem dein Magento läuft, zeigen dir in unter einer Minute, ob du betroffen bist:

crontab -l | grep -i gvfsd
ls -la ~/.local/share/.gvfsd/ ~/.cache/fontconfig/fc-cache /tmp/.kw_* /tmp/.cache_* /tmp/.gvfsd-* /tmp/.fc-*/fc-cache /tmp/fc-cache 2>/dev/null
ps -eo pid,comm,args | grep -iE 'kworker|fc-cache'
grep -ril 'x_trace_' var/report/

Ein kworker-Prozess, der nicht root gehört, ist immer verdächtig. Echte Kernel-Threads laufen nie unter dem Shop-Benutzer. Ein Treffer bei x_trace_ in var/report/ bedeutet, dass mindestens die erste Stufe des Angriffs stattgefunden hat.

Der zweite Indikator braucht kein Werkzeug: ungewöhnlich viele E-Mails „Payment Transaction Failed Reminder”, oft mit nicht aufgelösten Template-Variablen im Text. Echte abgelehnte Zahlungen erzeugen dieselbe Benachrichtigung, ein plötzlicher Schwall davon ist trotzdem ein Grund, sofort nachzusehen.

Die vollständige Liste der Indikatoren (C2-Adressen, Download-Hosts, SHA-256-Hashes, Dateipfade) pflegt Sansec in der laufend aktualisierten Analyse zu StyleSmuggler. Wer Firewall-Regeln oder ein SIEM füttert, nimmt die Werte von dort.

Sofortmaßnahmen, in dieser Reihenfolge

1. Angriffe blockieren: 360°-Rundumschutz oder Sansec Shield

Auf unseren Servern ist der schnellste Weg unser 360°-Rundumschutz. Er sitzt vor der Anwendung, prüft eingehende Anfragen auf Angriffsmuster und scannt das Dateisystem des Accounts auf Malware. Die StyleSmuggler-Angriffe hat er auf geschützten Accounts abgefangen, bevor die erste Stufe des Angriffs überhaupt greifen konnte, und das schon vor der Veröffentlichung durch Sansec. Für alle anderen Accounts schalten wir ihn auf Zuruf frei, ohne Änderung an deinem Magento-Code. Details und Preis stehen weiter unten.

Wer nicht bei uns hostet oder zusätzlich eine Magento-spezifische Firewall will, greift zu Sansec Shield. Das ist eine WAF Web Application Firewall: filtert HTTP-Anfragen an die Anwendung und blockiert bekannte Angriffsmuster. , die nicht als CDN-Vorschaltung läuft, sondern als Composer-Modul direkt in Magento. Die Regeln gegen StyleSmuggler sind seit dem 5. September, 07:15 UTC aktiv und wurden seither auf beide Angriffsstufen erweitert. Das ist aktuell der einzige Schutz, der die Lücke selbst abfängt, statt nur ihre Folgen zu begrenzen. Installation: composer require, setup:upgrade, Lizenzschlüssel eintragen. Shield braucht Magento 2.3 oder neuer und eine Advanced- oder Enterprise-Lizenz (Preise weiter unten).

2. Kompromittierung prüfen: eComscan

Die Firewall verhindert neue Angriffe. Ob du zwischen dem 4. September und deiner Absicherung bereits getroffen wurdest, sagt sie dir nicht. Dafür ist eComscan da, der Malware-Scanner von Sansec, der den Backdoor und mögliche zweite Hintertüren erkennt. Sansec hat mit Version 1.9.7 nachgezogen: Für Shield-Kunden beendet der Scanner die verdächtigen Prozesse automatisch. Wer keine Lizenz hat, kann zumindest die vier Befehle von oben ausführen.

3. Ohne Shield: GraphQL vorübergehend abschalten

Sansec empfiehlt, GraphQL zu deaktivieren, bis Adobe einen offiziellen Fix liefert. Das schließt den bekannten Einstiegspunkt. Der Preis dafür: Headless-Storefronts, PWA Studio, Hyvä Checkout und viele App-Anbindungen laufen über GraphQL und fallen dann aus. Für einen klassischen Luma-Shop ist das meist verschmerzbar, für einen Headless-Shop nicht. Und es bleibt eine Krücke: Die Lücke selbst ist damit nicht geschlossen, nur der bislang beobachtete Weg dorthin.

4. Inoffizielle Patches im Code

Die Community hat schneller reagiert als Adobe. Drei Quellen bieten Patches an, die an den kritischen Stellen der Kette ansetzen. Alle drei sind ausdrücklich Notlösungen ohne Gewähr, veröffentlicht von Leuten, die selbst betroffene Shops betreuen:

• ProxiBlue (Lucas van Staden) hat als Erster einen Patch-Satz im GitHub-Gist veröffentlicht. Kern: Die drei DI-Scanner-Methoden in magento2-base bekommen einen PHP_SAPI !== 'cli'-Guard, laufen also nur noch auf der Kommandozeile, nicht mehr im Web-Kontext. Dazu kommen ein Entschärfen von PHP-Tags in Fehlerberichten, eine Prüfung im URL-Generator des Backends und eine Sperre für Backend-Blöcke in E-Mail-Templates. Die Gist-Version ist auf Mage-OS 3.4.0 (entspricht Magento 2.4.9) getestet und für vaimo/composer-patches aufbereitet.
• Disrex pflegt ein Mitigation-Repository mit einem kombinierten Patch für magento/magento2-base, per Dry-Run gegen 2.4.6, 2.4.7, 2.4.8 und 2.4.9 geprüft. Die ProxiBlue-Patches liegen dort als eigenständige Variante bei, weil beide Teams unabhängig voneinander zur selben Lösung gekommen sind. Wichtig: nicht beide Varianten gleichzeitig anwenden, sie ändern dieselben Codestellen.
• Graycore liefert das Ganze als Composer-Modul (composer require graycore/magento2-style-smuggler-patch, dann module:enable). Es härtet drei Punkte der Kette: die {{block}}-Direktive in E-Mail-Templates, die URL-Generierung in Grid-Zeilen und die Fehlerberichte der Web-API. Für Magento 2.4, MIT-Lizenz.

Disrex schreibt selbst, dass der Guard auf einem Test-Harness und nicht in einem laufenden Shop getestet wurde. Wer die Patches einsetzt, liest sie vorher, testet auf Staging und ersetzt sie durch den offiziellen Fix, sobald Adobe einen liefert. Ergänzend empfiehlt Disrex, proc_open in der PHP-Konfiguration zu deaktivieren und /tmp, /var/tmp und /dev/shm mit noexec zu mounten. Das stoppt den Backdoor nicht in jedem Fall, macht dem Dropper aber das Leben schwer.

5. Falls du betroffen bist: aufräumen, dann Zugänge rotieren

Ein Patch entfernt keinen Backdoor, der schon läuft. Wenn einer der Indikatoren oben anschlägt, gilt: Prozess beenden, Cron-Einträge und Dateien entfernen, danach prüfen, ob weitere Hintertüren, unbekannte Admin-Konten oder fremde Integrations-Tokens angelegt wurden. Anschließend Magento-Admin-Passwörter, API-Tokens, Datenbank-Zugänge, SSH-Keys und Deployment-Credentials rotieren. Sansec hat bisher keinen Hinweis darauf, dass der Backdoor aktiv für Datenabfluss genutzt wurde. Verlassen würden wir uns darauf nicht: Ein Prozess, der auf Befehle wartet, kann jederzeit welche bekommen.

Was das für Kunden von rack::SPEED bedeutet

Die Lücke sitzt im Magento-Code, nicht in der Plattform darunter. Kein Betriebssystem-Update, kein Webserver-Patch und keine Kernel-Mitigation schließt sie. Was wir auf Server-Ebene tun können, ist zweierlei: die Angriffe abfangen, bevor sie Magento erreichen, und die Umgebung um Magento herum härten, damit ein erfolgreicher Angriff weniger Schaden anrichtet. Was im Application-Code passiert, entscheidest du mit deiner Agentur, so wie bei jedem Magento-Update.

Zusätzlich haben wir alle uns bekannten Angreifer-Adressen auf unseren Servern gesperrt, die aus der Sansec-Analyse und die aus unseren eigenen Logs. Das ist Hygiene, kein Schutz. Die Angreifer arbeiten aus Hyperscaler-Netzen wie AWS heraus, dort gibt es Adressen praktisch ohne Ende, und jede Sperrliste ist nur eine Momentaufnahme des Zustands von gestern. Wer sich darauf verlässt, ist beim nächsten Rechnungslauf des Angreifers wieder ungeschützt.

Deshalb vier Angebote, in der Reihenfolge, in der wir sie empfehlen:

360°-Rundumschutz für deinen Account. Unser Rundumschutz kombiniert eine Web Application Firewall mit Malware-Scanner und Intrusion Detection auf Account-Ebene. Genau diese Kombination hat die StyleSmuggler-Angriffe auf unseren Servern im Vorfeld blockiert: Die Anfragen auf /graphql?styles[...]= kamen an, wurden verworfen, und der Angreifer kam nie bis zur zweiten Stufe. Der Schutz kostet 25 € je Account auf dem Server, wir schalten ihn innerhalb der Geschäftszeiten frei, ohne Eingriff in deinen Code und ohne Deployment. Mehr Accounts auf demselben Server schützen wir auf Anfrage. Das ist die Maßnahme, die wir als Erstes empfehlen, weil sie am schnellsten steht und unabhängig davon wirkt, ob Adobe morgen patcht oder erst in zwei Wochen.

Sansec-Lizenzen mit 10 % Partner-Rabatt. Wir sind Sansec-Partner und geben den Partner-Rabatt auf eComscan und Sansec Shield an dich weiter. Die Listenpreise stammen von der Sansec-Preisliste, pro Monat, Stand 7. September 2026:

Plan	Für Shops bis	Listenpreis monatlich	Listenpreis jährlich	Mit 10 % Rabatt (monatlich / jährlich)
Sansec Secure	3 Mio. € Jahresumsatz	125 €	115 €	112,50 € / 103,50 €
Sansec Advanced	20 Mio. € Jahresumsatz	249 €	229 €	224,10 € / 206,10 €
Sansec Enterprise	50 Mio. € Jahresumsatz	629 €	575 €	566,10 € / 517,50 €

Alle Pläne enthalten eComscan mit Malware- und Schwachstellen-Erkennung. Sansec Shield ist ab Advanced dabei, ebenso Slack-Alerts, API-Anbindung und Multi-Store-Dashboard. Bei jährlicher Laufzeit von Advanced oder Enterprise übernimmt Sansec im Fall der Fälle Analyse und Cleanup. Enterprise deckt zusätzlich Cluster-Setups, Adobe Cloud und die PCI-DSS-Anforderungen 5 und 6.6 ab. Eine Lizenz gilt für einen Shop. Bestellung, Einrichtung und Lizenzschlüssel laufen über uns, du musst dich nicht bei Sansec registrieren.

Prüfung und Aufräumen als HandsOn-Einsatz. Wenn du nicht selbst nachsehen willst oder kannst, prüfen wir deinen Account auf die bekannten Indikatoren, beenden einen gefundenen Backdoor, entfernen Cron-Einträge und Dateien und dokumentieren, was wir vorgefunden haben. Das läuft als HandsOn-Einsatz zum Notfall-Satz: 50 € je angefangene 15 Minuten, die erste Stunde pauschal, wie in der HandsOn-Preisliste beschrieben. Die Patches im Magento-Code spielen wir nicht ein, das bleibt bei deiner Agentur oder deinem Team, so wie bei jedem anderen Eingriff in die Anwendung.

Härtung auf Server-Ebene. In unserem Magento-Hosting setzen wir proc_open-Sperren und noexec-Mounts auf Anfrage um, sofern dein Deployment das verträgt. Nicht jeder Build-Prozess kommt ohne aus, deshalb machen wir das nicht pauschal, sondern nach kurzer Rücksprache.

Wie es weitergeht

Der 8. September wird zeigen, ob Adobe die Lücke im regulären Bulletin schließt oder ob ein außerplanmäßiger Patch nötig wird. Sobald ein offizieller Fix vorliegt, gehört er in deinen Shop, egal welche Zwischenlösung du bis dahin fährst. Den Status halten wir wie bei jeder Sicherheitsmeldung, die unsere Plattform oder unsere Kunden betrifft, im Security-Log fest.

Bis dahin gilt die Reihenfolge von oben: Angriffe blockieren, Kompromittierung prüfen, Code härten, Zugänge rotieren, wenn nötig. Wer den 360°-Rundumschutz freischalten lassen will, eine Sansec-Lizenz oder Hilfe bei Prüfung und Aufräumen braucht, eröffnet ein Ticket im Kundencenter. Wer noch kein Kunde ist, erreicht uns über das Kontaktformular.

Quellen: Sansec: StyleSmuggler, Magento and Adobe Commerce 0-day RCE under active attack · Konvis: StyleSmuggler, kritische Magento-0-Day-Lücke wird bereits aktiv ausgenutzt · The Hacker News: Unpatched Magento and Adobe Commerce zero-day exploited · ProxiBlue-Gist · Disrex-Mitigation-Repository · Graycore-Patch-Modul