50 Minuten. So lange dauerte es vom ersten bestätigten Angriff auf die Magento-Sicherheitslücke CVE-2026-75650 bis zur Kompromittierung eines vollständig gepatchten Shops, wie die niederländische Entwicklungsplattform Disrex dokumentiert. Am Montag hat Adobe reagiert und einen Hotfix für den Zero-Day veröffentlicht, der seit dem 4. September 2026 aktiv ausgenutzt wird. Für Betreiber von Adobe Commerce und Magento Open Source gibt es derzeit nur eine sinnvolle Aufgabe: patchen, Schlüssel rotieren, Logs prüfen.
Die Sicherheitsfirma Sansec hat die Lücke entdeckt und ihr den Namen „StyleSmuggler“ gegeben. Die CVSS-Bewertung liegt bei 10,0 – dem Maximalwert. Ausgenutzt wird Magentos eigenes Template-System: Über PHP-Code-Injection erzeugen die Angreifer eine „Payment Transaction Failed Reminder“-E-Mail, bei deren Verarbeitung der eingeschleuste Code ausgeführt wird. Authentifizierung ist dafür nicht nötig. Jeder Shop, der aus dem Internet erreichbar ist, war potenziell angreifbar.
Welche Magento-Versionen sind betroffen?
Die Antwort ist unangenehm breit: praktisch alle gängigen Installationen. Verwundbar sind Adobe Commerce 2.4.4 bis 2.4.9 jeweils inklusive der August-2026-Patches, Magento Open Source 2.4.6 bis 2.4.9 sowie die B2B-Erweiterungen in den Versionen 1.3.3 bis 1.5.3. Wer auf einer dieser Versionen läuft und seit vergangener Woche nicht gepatcht hat, muss von einem Angriffsversuch ausgehen.
Adobe stellt den Fix als Hotfix-Paket „VULN-39341″ über das Composer-Repository bereit, nicht als reguläres Release. Zwei Schritte sind laut Adobe Pflicht: den Patch einspielen und die Encryption Keys rotieren. Wer nur patcht, ohne die Schlüssel zu wechseln, lässt Angreifern möglicherweise bereits erbeutete Zugänge offen.
Rust-Backdoor und PHP-Web-Shell: Was die Angreifer installieren
Beobachtet wurden zwei Angriffsmuster. Zum einen eine Rust-basierte Backdoor für Linux, die sich als Kernel-Thread tarnt – zunächst unter dem Namen „[kworker/u:8:0]“, später als „fc-cache“ oder „chronyd“, also als legitimer Zeitdaemon. Das Implantat liegt bewusst außerhalb des Web-Root, etwa im Home-Verzeichnis des Site-Users oder unter /tmp, und hält Verbindungen zum eigenen Redis-Server, um Magentos Session-Speicher auszulesen. Klassische Malware-Scans des Web-Verzeichnisses finden es nicht. Zum anderen wird ein PHP-Dropper eingeschleust, der eine Web-Shell für beliebige Code-Ausführung schreibt.
Sansec beschreibt einen Fall, in dem eine infizierte Zeile 1.728 Mal in einer Datei stand – und sich innerhalb einer Sekunde nach dem Löschen selbst wieder einsetzte. Wer also auf seinem Server Auffälligkeiten entdeckt, sollte nicht auf Dateiebene aufräumen, sondern das System als kompromittiert behandeln.
Was heißt das für den Shop-Alltag?
Kurzfristig: Patchfenster sofort öffnen, auch außerhalb der üblichen Wartungszyklen. Die Honeypot-Daten von Previdian zeigen zwölf Angriffsversuche allein seit dem 7. September, gestartet von IP-Adressen aus China und Rumänien – die Scans laufen automatisiert und treffen jeden erreichbaren Shop.
Mittelfristig lohnt ein Blick auf die Absicherung darunter. Sansec bietet mit eComscan einen auf Magento spezialisierten Scanner, der bekannte Backdoor-Signaturen auch außerhalb des Web-Root erkennt; alternativ helfen Server-seitige WAF-Regeln, die die bekannten Exploit-Pfade blockieren. Beides ersetzt den Patch nicht, deckt aber das Zeitfenster bis zum nächsten Update ab.
Dass es mit StyleSmuggler innerhalb weniger Monate schon wieder eine unauthentifizierte Remote-Code-Execution im Magento-Kern trifft, ist kein Zufall. Die Angriffsfläche des Template-Systems ist bekannt, die monetäre Motivation – Kreditkartendaten, Sessions, Kundendaten – bleibt hoch. Händler, die Magento selbst hosten, sollten ihre Patch-Prozesse auf Stunden statt Wochen auslegen. Wer das nicht leisten kann, muss sich die Frage stellen, ob Self-Hosting für den eigenen Shop noch das richtige Modell ist.