Adobe hat CVE-2026-75650 geschlossen, eine kritische Sicherheitslücke in Adobe Commerce und Magento Open Source, die Angreifer ausnutzten, bevor ein Fix verfügbar war. Die nicht authentifizierte Lücke zur Remotecodeausführung hat einen CVSS-Score von 10,0 und wird von der Sicherheitsfirma Sansec als „StyleSmuggler“ geführt.
Der Hotfix VULN-39341 schließt die Sicherheitslücke, doch Shops, die vor dem Patch kompromittiert wurden, können weiterhin persistente Malware oder offengelegte Zugangsdaten enthalten. Adobe weist Händler an, nicht nur die Verschlüsselungsschlüssel von Commerce zu erneuern, sondern auch Passwörter, Tokens, Zahlungsdaten, Datenbankzugangsdaten und andere Geheimnisse, auf die Angreifer möglicherweise Zugriff hatten.
Die APSB26-146-Advisory bestätigt die Ausnutzung in freier Wildbahn und erklärt, dass ein Angreifer keine Authentifizierung benötigt, um beliebigen Code auszuführen. Verteidiger sollten die Lücke nicht allein anhand ihres CVSS-Scores einstufen, denn die aktive Ausnutzung und die Persistenz erhöhen die Dringlichkeit über die reine Schweregradbewertung hinaus.
Wie StyleSmuggler Magento-Shops kompromittiert
Sansec zufolge erfolgte die erste bestätigte Ausnutzung am 4. September um 22:20 UTC. Später reproduzierte Sansec die vollständige nicht authentifizierte Angriffskette auf sauberen Installationen von Magento Open Source 2.4.7, 2.4.8 und 2.4.9.
Der Exploit missbraucht Magentos Templatesystem. Angreifer schleusen zunächst PHP-Code in Daten ein, die Magento später verarbeitet, und lösen dann die E-Mail „Payment Transaction Failed Reminder“ der Plattform aus, sodass Magento den manipulierten Code ausführt.
Kein Mitarbeiter und kein Kunde muss die E-Mail öffnen. Der Schadcode wird ausgeführt, während Magento die Nachricht rendert, und der Angriff kann auch dann erfolgreich sein, wenn die Zustellung fehlschlägt.
Bei einem erfolgreichen Angriff kann Malware außerhalb des Webroots installiert werden. Sansec beobachtete zunächst ein Rust-Implantat, das sich hinter dem Prozessnamen [kworker/u:8:0] verbargfc-cache und später chronyd verwendete, um gewöhnliche Linux-Prozesse nachzuahmen.
Auch die Persistenz hat sich zwischen den Implantatvarianten verändert. Einige Versionen legten Cron-Jobs an, die die Malware neu starteten, während eine chronyd Variante ganz ohne Cron-Eintrag neu gestartet wurde. Eine leere Crontab beweist daher nicht, dass ein Host sauber ist.
Disrex, das kompromittierte Magento-Server direkt untersuchte, berichtete, dass ein verwalteter Server bereits 50 Minuten nach der ersten bestätigten StyleSmuggler-Ausnutzung getroffen wurde. Der Server war vollständig gegen zuvor bekannte Sicherheitslücken gepatcht.
Bei den SessionReaper-Angriffen im Jahr 2025 setzten Angreifer ebenfalls PHP-Webshells ein, um nach der Ausnutzung von Magento den Zugriff aufrechtzuerhalten. Das ist ein weiterer Grund für Verteidiger, nach dem Schließen des ursprünglichen Einfallstors auf Persistenz zu prüfen.
Wer den Adobe-Hotfix benötigt
Adobe führt betroffene Adobe-Commerce-Zweige von 2.4.4 bis 2.4.9 auf, einschließlich ihrer Builds vom August 2026 und früherer Releases dieser Zweige. Ebenfalls betroffen sind Adobe-Commerce-B2B-Versionen aus den betroffenen Zweigen 1.3.3 bis 1.5.3.
Die Zweige von Magento Open Source 2.4.6, 2.4.7, 2.4.8 und 2.4.9 sind betroffen.
Adobe weist Kunden an, den für ihre Version passenden Composer-Hotfix VULN-39341 zu installieren. Für Adobe Commerce in der Cloud stellt Adobe außerdem einen Befehl für das Quality Patches Tool bereit, mit dem sich überprüfen lässt, ob der Hotfix den Status Applied aufweist.
Das Commerce-Sicherheitsrelease vom September 2026 macht diese Anforderung nicht überflüssig. In APSB26-138 weist Adobe Kunden ausdrücklich an, den Hotfix für CVE-2026-75650 zusätzlich zu den Sicherheitsupdates vom September anzuwenden.
Adobe zufolge wurde der Hotfix auf den aufgeführten Versionen vom August 2026 getestet. Er funktioniert möglicherweise auch mit anderen unterstützten Konfigurationen, doch Adobe hat diese Kombinationen nicht verifiziert.
Wonach Verteidiger nach dem Patch suchen sollten
Sansec hat seit Beginn der Kampagne mehrere Implantatvarianten beobachtet. Verteidiger sollten sich daher nicht auf einen einzigen Datei- oder Prozessnamen verlassen.
| Indikator | Was zu untersuchen ist |
|---|---|
[kworker/u:8:0] | Ein Prozess mit einem Namen im Stil eines Kernel-Threads unter einem Nicht-Root-Magento-Benutzer |
fc-cache | Unerwarteter Prozess oder unerwartete Binärdatei unter ~/.cache/fontconfig/ oder in temporären Verzeichnissen |
chronyd | Unerwarteter chronyd-Prozess unter /tmp/.chrony-* statt im normalen Systempfad |
gvfsd-user | Binärdatei unter ~/.local/share/.gvfsd/ |
| Cron-Änderungen | Jobs, die gvfsd-user, fc-cache oder chronyd starten, einschließlich direkter Änderungen an Cron-Spool-Dateien |
| Datenverkehr auf UDP-Port 123 | Ungewöhnlicher, NTP-ähnlicher ausgehender Datenverkehr vom Magento-Host |
PHP unter pub/media | Unerwartete PHP-Dateien, die auf eine sekundäre Webshell hindeuten können |
Sansec zufolge nutzte ein separater Angreifer den StyleSmuggler-Zugriff ebenfalls, um eine PHP-Webshell unter dem Cache für Produktbilder zu installieren. Diese Payload war unabhängig vom primären Rust-Implantat. Das Auffinden oder Entfernen einer bekannten Malware-Familie schließt daher eine zusätzliche Kompromittierung nicht aus.
Sansec zufolge kann eComscan bekannte StyleSmuggler-Hintergrundprozesse erkennen und für Shield-Kunden beenden. Das Unternehmen hat die Erkennung weiter verbessert, während neue Implantatvarianten aufgetaucht sind.
Sansec hat keine Hinweise darauf gemeldet, dass die primäre Hintertür zum Ausführen von Befehlen durch Angreifer verwendet wurde. Bereits kompromittierte Hosts müssen jedoch weiterhin untersucht werden.
Während der Eindämmung sollten Teams die unnötige Angriffsfläche reduzieren, indem sie exponierte Dienste begrenzen und ausgehende Verbindungen, wo praktikabel, einschränken. Dadurch kann es für Implantate schwieriger werden, die Command-and-Control-Infrastruktur zu erreichen, während der Host untersucht wird.
Warum Adobe die Erneuerung von Zugangsdaten verlangt
Adobe warnt, dass die Änderung des Commerce-Verschlüsselungsschlüssels keine Geheimnisse ungültig macht, die ein Angreifer möglicherweise bereits erlangt hat.
Nach der Anwendung des Hotfixes umfasst die von Adobe empfohlene Abfolge zur Behebung, den Shop in den Wartungsmodus zu versetzen, Cron zu deaktivieren und Folgendes zu erneuern:
- Commerce-Verschlüsselungsschlüssel und Administratorpasswörter
- REST-, SOAP- und GraphQL-Integrationstokens
- OAuth-Client-Geheimnisse
- Zugangsdaten für Zahlungs-Gateways bei Anbietern wie Stripe, Braintree, Adyen und PayPal
- Datenbankzugangsdaten
- SSH- und Deployment-Schlüssel
- Zugangsdaten privilegierter Dienstkonten
- Schlüssel für APIs von Versand-, Steuer- und anderen Drittanbietern
Anschließend weist Adobe Händler an, die Caches zu leeren, die Cron-Ausführung wiederherzustellen und den Wartungsmodus nach Abschluss der Erneuerung zu verlassen.
Zahlungsdaten und Zugangsdaten von Drittanbietern sollten beim externen Anbieter geändert werden, nicht nur innerhalb von Adobe Commerce. Wenn ein Angreifer ein gültiges Geheimnis bereits kopiert hat, wird diese Zugangsdaten nicht dadurch widerrufen, dass Commerce die gespeicherte Kopie anders verschlüsselt.
Shops, die vor dem Hotfix vom 7. September offengelegt waren, sollten CVE-2026-75650 als Incident-Response-Problem und nicht nur als Patch-Aufgabe behandeln. Wenden Sie den Hotfix an, verifizieren Sie ihn, sofern Adobe eine unterstützte Prüfung bereitstellt, suchen Sie nach Persistenz, erneuern Sie möglicherweise offengelegte Zugangsdaten und untersuchen Sie verdächtige Aktivitäten, bevor Sie den Shop wieder in den Normalbetrieb überführen.
Auch lesen: Google hat CVE-2026-85046 gepatcht , nachdem eine Ausnutzung in freier Wildbahn bestätigt worden war – damit war es der sechste im Jahr 2026 behobene Chrome-Zero-Day.