CVSS 10.0 – die höchstmögliche Bewertung. Die Sicherheitslücke CVE-2026-75650, getauft auf den Namen StyleSmuggler, betrifft Magento Open Source und Adobe Commerce in den Versionen 2.4.4 bis 2.4.9. Seit dem 4. September 2026 läuft eine aktive Angriffswelle. Entdeckt hat sie das niederländische Security-Unternehmen Sansec, das die Angriffskette binnen Stunden auf frischen Installationen der Versionen 2.4.7, 2.4.8 und 2.4.9 nachstellen konnte.
Das Unangenehme zuerst: Ein aktueller Patchstand schützt nicht. Das erste bekannte Opfer lief auf Magento 2.4.6-p15 – mit allen Juli- und August-Patches, ohne offene Sicherheitsmeldungen. Die Angreifer brauchen weder Zugangsdaten noch eine Admin-Session. Sie schmuggeln PHP-Code über die styles-Properties des Template-Systems ein und lassen ihn von Magento selbst ausführen – ausgerechnet über die Standard-Mail „Payment Transaction Failed Reminder“. Niemand muss die E-Mail öffnen; der Schadcode läuft bereits, während Magento sie rendert. Wer in den letzten Tagen ungewöhnlich viele fehlgeschlagene Zahlungs-Mails gesehen hat, sollte das nicht als Zufall abtun.
Was passiert nach einem erfolgreichen Angriff?
Die Antwort ist ungewöhnlich professionell. Der Schädling installiert einen in Rust geschriebenen Hintergrundprozess, der sich als Systemdienst tarnt – zunächst als „[kworker/u:8:0]“, ab dem 6. September als „fc-cache“, seit dem 7. September als „chronyd“, also unter dem Namen des echten Linux-Zeitdienstes. Die Kommunikation mit dem Command-and-Control-Server läuft als getarnter NTP-Verkehr über UDP-Port 123 und fällt damit durch die meisten Firewall-Filter. Die Betreiber iterieren schnell: Sansec beobachtet mehrere Payload-Wechsel pro Tag. Zudem nutzt bereits eine zweite, unabhängige Tätergruppe dieselbe Lücke, um Webshells im Produktbilder-Cache unter pub/media abzulegen.
Hotfix VULN-39341: Was Adobe jetzt liefert
Adobe reagierte am 7. September um 20:20 UTC mit dem Security Bulletin APSB26-146, Priorität 1 – die höchste Stufe. Der Fix kommt nicht als reguläres Release, sondern als Composer-Hotfix: Das Paket VULN-39341-composer-patches.zip von repo.magento.com einspielen und die Installation per vendor/bin/magento-patches -n status verifizieren. Getestet hat Adobe den Hotfix gegen die August-2026-Releases von Adobe Commerce und Magento Open Source 2.4.4 bis 2.4.9 sowie Adobe Commerce B2B 1.3.3 bis 1.5.3. Ältere Patch-Level sind ebenfalls verwundbar, dort ist der Fix aber ungetestet – ein weiteres Argument, auf den aktuellen Patchstand zu ziehen.
Woran erkenne ich, ob mein Shop betroffen ist?
Drei Prüfungen geben schnell Klarheit. Erstens: Prozessliste nach kworker, fc-cache und chronyd durchsuchen – die echte chronyd-Installation liegt nicht unter /tmp. Zweitens: Cron-Spool-Dateien direkt prüfen, nicht nur über crontab -l; der Schädling schreibt seine Einträge teils am Cron-Daemon vorbei. Drittens: find pub/media -name '*.php' – im Medienverzeichnis hat kein PHP-File etwas zu suchen. Wer die Sansec-Extension eComscan im Einsatz hat, bekommt die Implants mit Version 1.9.7 automatisch angezeigt; Sansec Shield blockiert die Angriffe seit dem 5. September in Echtzeit.
Bei einem Befund folgt der aufwendige Teil. Adobe empfiehlt, den Magento-Encryption-Key zu rotieren – und alles, was dieser Key schützt: Admin-Passwörter, REST- und GraphQL-Integrations-Tokens, OAuth-Secrets, Payment-Gateway-Zugänge, Datenbank-Credentials, SSH- und Deploy-Keys sowie API-Keys von Drittanbieter-Extensions. Rotiert werden muss an der Quelle, nicht nur innerhalb von Magento. Wer den Key bereits bei einem früheren Vorfall wie CosmicSting oder SessionReaper getauscht hat, weiß: Das ist kein Nachmittagsjob, sondern ein koordinierter Eingriff über Hoster, Payment-Provider und Agentur hinweg.
Ein Angreifer mit dem Encryption-Key kann Admin-Sessions fälschen, lange nachdem gepatcht wurde.
Die Reihenfolge für die nächsten 48 Stunden ist klar: Hotfix einspielen, Server nach den genannten Indikatoren scannen, bei Befund Credentials rotieren. Magento- und Adobe-Commerce-Betreiber, die das bis zum Wochenende aufschieben, setzen darauf, dass die Tätergruppen ihre eigene Infrastruktur nicht schneller umbauen als die IT-Verantwortlichen ihre Wartungsfenster. Die Beobachtungen der letzten fünf Tage sprechen dagegen.