50 Minuten. So lange dauerte es vom ersten bestätigten Angriff auf die Magento-Lücke CVE-2026-75650 bis zur Kompromittierung eines vollständig gepatchten Servers – dokumentiert von der Incident-Response-Firma Disrex. Seit dem 4. September 2026 nutzen Angreifer die Schwachstelle aktiv aus. Adobe hat am 7. September mit dem Bulletin APSB26-146 reagiert, die US-Behörde CISA nahm die Lücke am 8. September in ihren Katalog bekanntermaßen ausgenutzter Schwachstellen auf. Für Betreiber von Adobe-Commerce- und Magento-Open-Source-Shops ist das kein routinemäßiges Patch-Management, sondern ein Fall für die Incident Response.
Was steckt hinter „StyleSmuggler“?
Die Sicherheitsfirma Sansec, die die Kampagne entdeckt hat und ihr den Namen StyleSmuggler gab, stuft die Lücke mit dem maximalen CVSS-Score von 10,0 ein: unauthentifizierte Remote Code Execution. Jeder, der den Shop aus dem Netz erreicht, kann ohne Login beliebigen Code auf dem Server ausführen. Betroffen sind Adobe Commerce 2.4.4 bis 2.4.9, Adobe Commerce B2B 1.3.3 bis 1.5.3 sowie Magento Open Source 2.4.6 bis 2.4.9 – samt der August-2026-Builds dieser Zweige.
Der Angriffsweg ist ungewöhnlich und erklärt, warum klassische Web Application Firewalls hier versagen können. Angreifer schleusen PHP-Code über Style-Eigenschaften in die Template-Engine ein. Magento schreibt diese Daten im Rahmen normaler Prozesse auf die Festplatte. Ausgeführt wird der Code, sobald die Plattform die Transaktionsmail „Payment Transaction Failed Reminder“ rendert – eine Mail, die bei fehlgeschlagenen Zahlungen ohnehin regelmäßig ausgelöst wird. Weder Mitarbeiter noch Kunden müssen die Mail öffnen; der Schadcode läuft bereits beim Rendern, selbst wenn der Versand scheitert.
Warum reicht der Hotfix VULN-39341 nicht aus?
Adobe liefert den Fix als Composer-Hotfix VULN-39341; für Commerce on Cloud lässt sich über das Quality Patches Tool prüfen, ob der Status auf „Applied“ steht. Wer bereits das September-Sicherheitsrelease (APSB26-138) eingespielt hat, ist nicht automatisch geschützt – Adobe verlangt den Hotfix ausdrücklich zusätzlich. Doch selbst ein verifiziert angewendeter Patch sagt nichts über den Zustand des Servers aus.
Ein leerer Crontab beweist nicht, dass ein Host sauber ist.
Sansec beobachtet mehrere Varianten eines Rust-basierten Implants, das sich hinter harmlos klingenden Prozessnamen wie [kworker/u:8:0], fc-cache oder chronyd versteckt – teils mit Cron-Jobs zur Wiederbelebung, teils ganz ohne. Zusätzlich wurden PHP-Web-Shells im Produktbild-Cache unter pub/media gefunden, die von einem zweiten Akteur stammen und mit dem Hauptimplant nichts zu tun haben. Wer eine Malware-Familie findet und entfernt, hat damit noch lange keine Gewissheit.
Konkrete Schritte für Shopbetreiber
Die Reihenfolge folgt Adobes Remediation-Leitfaden und den Befunden von Sansec. Zuerst Hotfix einspielen und verifizieren, dann den Shop in den Wartungsmodus versetzen und Cron deaktivieren. Anschließend steht die Credential-Rotation an: Commerce-Verschlüsselungsschlüssel und Admin-Passwörter, Integrations-Tokens für REST, SOAP und GraphQL, OAuth-Secrets, Datenbankzugänge, SSH- und Deployment-Keys sowie die Zugangsdaten bei Zahlungsdienstleistern wie Stripe, Adyen, Braintree oder PayPal. Der wichtige Punkt dabei: Payment- und Drittanbieter-Credentials müssen beim jeweiligen Anbieter rotiert werden, nicht nur im Shop. Ein neuer Encryption Key in Adobe Commerce macht ein bereits kopiertes Stripe-Secret nicht ungültig.
Parallel gehört der Server auf Indikatoren untersucht: unerwartete Prozesse unter /tmp/.chrony-* oder ~/.cache/fontconfig/, PHP-Dateien unter pub/media, verdächtiger ausgehender Traffic auf UDP-Port 123. Für die Prüfung lassen sich bestehende Magento-Sicherheitswerkzeuge nutzen – Sansecs eComscan erkennt und beendet die bekannten StyleSmuggler-Hintergrundprozesse inzwischen automatisch, MageReport bietet einen kostenlosen externen Patch-Check. Erst nach dieser Jagd auf Persistenz werden Caches geleert, Cron reaktiviert und der Wartungsmodus beendet.
Dass Adobe-Kunden jetzt Zugangsdaten bei Zahlungsanbietern rotieren müssen, zeigt die eigentliche Dimension: Eine Template-Lücke in der E-Mail-Rendering-Kette reicht, um die komplette Vertrauenskette eines Shops zu kippen. Wer seine Payment-Integrationen bisher als abgekapseltes Risiko behandelt hat, sollte dieses Wochenende umdenken.