Seit dem 4. September 2026, 22:20 Uhr UTC, läuft eine Angriffswelle auf Magento- und Adobe-Commerce-Shops, und es gibt keinen offiziellen Patch. Die Sicherheitsfirma Sansec hat die Lücke „Style Smuggler“ getauft und auf sauberen Installationen von Magento Open Source 2.4.7, 2.4.8 und 2.4.9 nachvollzogen. Das erste bekannte Opfer lief auf 2.4.6-p15, vollständig gepatcht mit den Juli- und August-Updates. Gepatcht sein reicht also nicht.
Das ist der entscheidende Punkt für Shopbetreiber: Style Smuggler ist ein 0-Day. Adobe Enterprise Support bestätigte am 7. September, an einem Fix zu arbeiten, ohne Termin. Das nächste reguläre Sicherheitsrelease steht für den 8. September im Kalender, ob es diese Lücke schließt, ist offen.
Wie funktioniert der Angriff über die Payment-Mails?
Die Angriffskette läuft in zwei Stufen. Zuerst injizieren die Angreifer PHP-Code über die styles-Eigenschaft von Magentos Templatesystem per GraphQL-Request, ein Pfad, an dem bestehende Schutzmechanismen vorbeigehen. Danach lösen sie gezielt Magentos Standard-Mail „Payment Transaction Failed Reminder“ aus. Beim Rendern dieser E-Mail führt Magento den vergifteten Code aus. Niemand muss die Mail öffnen, der Angriff funktioniert selbst dann, wenn der Versand scheitert.
Ein Praxisdetail zeigt, wie ernst die Lage ist: Bei einem Händler scheiterte der erste Angriffsversuch am Session-Storage. Acht Sekunden später gelang derselbe Angreifer über einen Upload durch Magentos Custom Options. Wer seine Sessions auf Redis oder in die Datenbank verlagert hat, ist trotzdem angreifbar.
Rust-Backdoor tarnt sich als Systemprozess
Bei Erfolg startet im Hintergrund ein in Rust geschriebenes Implantat, das sich als [kworker/u:8:0], fc-cache oder seit dem 7. September als chronyd tarnt. Die Command-and-Control-Kommunikation läuft als NTP-getarnter UDP-Verkehr auf Port 123, ein Trick, der die meisten Egress-Filter passiert, weil er wie normale Zeitsynchronisation aussieht. Sansec dokumentiert zudem einen zweiten, unabhängigen Angreifer, der über dieselbe Lücke eine PHP-Webshell in den Produktbilder-Cache unter pub/media/catalog/product/cache/ schreibt.
Händler sollten ihre Server jetzt konkret prüfen, nicht pauschal:
- Prozessliste nach
kworker,fc-cacheundchronyddurchsuchen, die nicht aus Systempaketen stammen find pub/media -name '*.php'ausführen, im Media-Verzeichnis hat PHP nichts verloren- Auth-Logs nach „crontab command not allowed“ greppen; der Eintrag verrät Infektionszeitpunkt auf die Sekunde
- Temp-Verzeichnisse nach Pfaden wie
/tmp/.chrony-*oder/tmp/.fc_*absuchen
Ein wichtiger Hinweis von Sansec: Ein leerer Crontab ist kein Sauberkeitsbeweis. Die aktuelle Variante startet sich ohne Cron-Eintrag neu, und ein zweiter Fund wurde direkt in die Cron-Spool-Datei geschrieben, crontab -l zeigt ihn nicht.
Was tun, bis Adobe liefert?
Offiziellen Schutz gibt es bislang nur kommerziell: Sansec Shield blockiert die Angriffe seit dem 5. September in Echtzeit, eComscan 1.9.7 erkennt das Implantat und beendet die Prozesse. Wer keinen Sansec-Schutz einsetzt, kann als Notmaßnahme GraphQL deaktivieren, sofern der Storefront das verkraftet. Die Agentur Graycore hat zusätzlich einen inoffiziellen Stop-Gap-Patch auf GitHub und Packagist veröffentlicht, der drei Punkte der Angriffskette härtet: die {{block}}-Direktive in E-Mail-Templates, den Grid-Row-URL-Generator und die Fehlerberichte der Web-API. Graycore weist selbst ausdrücklich darauf hin, dass das Härtung ist, kein Fix, andere Pfade durch die Lücke bleiben offen.
Die Lücke reiht sich ein in ein düsteres Muster: Nach CosmicSting, SessionReaper (CVE-2025-54236) und der PolyShell-Welle ist Style Smuggler die vierte schwere Magento-Kampagne binnen gut eines Jahres. Wer nach einem Fund die Prozesse nur killt, hat gewonnen, nichts. Zugangsdaten rotieren, Media-Verzeichnis prüfen und das Adobe-Bulletin vom 8. September mit oberster Priorität einspielen: Das ist die Reihenfolge, die zählt.