StyleSmuggler (CVE-2026-75650): Patchen allein reinigt keinen Magento-Shop

Adobe hat am 7. September 2026 um 20:20 UTC einen außerplanmäßigen Hotfix veröffentlicht. Er schließt CVE-2026-75650, eine Schwachstelle in Adobe Commerce, Adobe Commerce B2B und Magento Open Source mit CVSS 10.0, die einem nicht authentifizierten Angreifer die Ausführung beliebigen Codes erlaubt. Adobe hat die Meldung mit der höchsten Dringlichkeitsstufe versehen.

Entdeckt wurde die Lücke von Sansec, das ihr den Namen StyleSmuggler gab. Die Angriffe begannen am 4. September, also drei Tage vor dem Patch. Die CISA hat die Schwachstelle am 8. September in den KEV-Katalog aufgenommen und US-Bundesbehörden eine Frist bis zum 11. September gesetzt.

Für Shop-Betreiber ergibt sich daraus eine Lage, die von der üblichen Patch-Routine abweicht: Es gab ein Zeitfenster, in dem angegriffen wurde und kein Patch existierte. Wer in diesem Fenster verwundbar im Netz stand, muss davon ausgehen, dass ein Zugriffsversuch stattgefunden hat.

Wie der Angriff funktioniert

StyleSmuggler nutzt Magentos eigenes Template-System. Der Angriff läuft in zwei Stufen. Zuerst wird PHP-Code in das System eingeschleust, beispielsweise über die Erzeugung eines Fehlerberichts. Anschließend bringt der Angreifer Magento dazu, den eingeschleusten Code auszuführen, indem er eine fehlgeschlagene Zahlungsbenachrichtigung auslöst.

Zwei Eigenschaften machen die Lücke besonders unangenehm. Über die Verwendung von Style-Eigenschaften umgeht der Angriff bestehende Schutzmechanismen im Template-System. Und die Codeausführung findet bereits beim Rendern der Vorlage statt, nicht beim Versand. Der Angriff gelingt deshalb auch dann, wenn der E-Mail-Versand fehlschlägt.

Betroffene Versionen

Betroffen sind alle Versionen von 2.4.4 bis einschließlich 2.4.9.

Der Fix ist ein Hotfix, kein vollständiges Release. Das Paket VULN-39341-composer-patches.zip wird über repo.magento.com bezogen und als Composer-Patch eingespielt. Die korrekte Installation lässt sich anschließend prüfen:

vendor/bin/magento-patches -n status | grep "39341\|Status"

Adobe hat den Hotfix gegen die August-Releases von Adobe Commerce 2.4.4 bis 2.4.9, Magento Open Source 2.4.4 bis 2.4.9 und Adobe Commerce B2B 1.3.3 bis 1.5.3 getestet. Ältere Stände innerhalb dieser Zweige sind ebenfalls verwundbar, dort ist der Patch aber nicht verifiziert.

Für die Zweige 2.2 und 2.3 sowie für 2.4.0 bis 2.4.3 veröffentlicht Adobe nichts, diese Stände sind außerhalb der Wartung. Scandiweb hat den Fix auf 41 ältere Releases zurückportiert. Sansec hat diese Portierungen nicht geprüft, ein Test auf einer Staging-Kopie ist vor dem Einsatz angeraten.

Wer eine dieser nicht mehr unterstützten Versionen produktiv betreibt, hat allerdings ein Problem, das über diese eine Schwachstelle hinausgeht.

Der Teil, den die meisten Meldungen auslassen

Der Patch schließt die Lücke. Er entfernt nicht, was ein Angreifer vorher hinterlassen hat.

Sansec hat auf denselben betroffenen Shops Aktivitäten von mindestens zwei verschiedenen Akteuren dokumentiert: eine Gruppe, die ein dauerhaftes Implantat installierte, und einen davon unabhängigen zweiten Angreifer, der eine PHP-Webshell im Produktbild-Cache ablegte. Techniken und Werkzeuge unterscheiden sich deutlich, Sansec behandelt sie als getrennte Kampagnen.

Beobachtet wurden ein in Rust geschriebenes Linux-Backdoor und PHP-Webshells. Die Command-and-Control-Kommunikation des Backdoors ist als NTP-Verkehr getarnt und läuft über Hostnamen, die wie Zeitserver aussehen.

Ein gepatchter Shop mit einer Webshell im Bild-Cache ist kein sicherer Shop. Er ist ein kompromittierter Shop, dem der ursprüngliche Einstiegsweg fehlt.

Was jetzt zu prüfen ist

Wer zwischen dem 4. und dem 7. September eine verwundbare Instanz erreichbar hatte, sollte die folgenden Punkte durchgehen.

Auffällige Zahlungs-E-Mails. Der Angriff erzeugt Benachrichtigungen über fehlgeschlagene Zahlungstransaktionen. Ein ungewöhnlicher Anstieg dieser Mails im fraglichen Zeitraum ist ein direkter Hinweis.

Ausgehende Verbindungen auf Port 123. Der getarnte C2-Verkehr sieht aus wie NTP, geht aber an Ziele, die kein Zeitserver der eigenen Konfiguration sind. Ein Abgleich der ausgehenden UDP-Verbindungen gegen die konfigurierten NTP-Server ist schnell gemacht und aussagekräftig.

Dateien im Produktbild-Cache. PHP-Dateien in Verzeichnissen, die ausschließlich Bilder enthalten sollten, sind immer auffällig. Das gilt unabhängig von diesem Vorfall.

Prozessstarts unterhalb des Webservers. Wenn PHP-FPM oder der Webserver eine Shell startet, ist das im Normalbetrieb eines Shops nicht zu erwarten.

Änderungen im Dateisystem im fraglichen Zeitraum. Neue oder veränderte Dateien unterhalb des Webroots zwischen dem 4. und dem Zeitpunkt des Patches.

Wenn sofortiges Patchen nicht möglich ist

Als Übergangsmaßnahmen kommen in Betracht: die vorübergehende Deaktivierung von GraphQL, die Aufnahme von proc_open in die disable_functions-Direktive von PHP sowie das Einhängen von /tmp, /var/tmp und /dev/shm ohne Ausführungsrecht.

Diese Maßnahmen erschweren die Nachnutzung. Sie ersetzen den Patch nicht.

Meldepflichten

Hier unterscheidet sich die Lage von einem gewöhnlichen Patchday, und dieser Punkt wird in der Berichterstattung meist übergangen.

Ein Magento-Shop verarbeitet personenbezogene Daten von Kunden und liegt in aller Regel im Geltungsbereich von PCI DSS. Bestätigt sich eine Kompromittierung, greift Artikel 33 DSGVO: Meldung an die zuständige Aufsichtsbehörde binnen 72 Stunden nach Bekanntwerden. Bei hohem Risiko für die Betroffenen kommt die Benachrichtigung der Kunden nach Artikel 34 hinzu.

Das betrifft auch Betreiber, die nicht unter NIS2 fallen. Der typische Mittelstandsshop ist keine wesentliche Einrichtung, aber er ist Verantwortlicher im Sinne der DSGVO.

Die Frist läuft ab Kenntnis. Wer nicht prüft, erlangt keine Kenntnis, und die Frist beginnt nicht. Das verschiebt das Problem allerdings nur: Der Zeitpunkt einer Kompromittierung lässt sich forensisch bestimmen, und wenn Kartendaten später auffällig werden, steht die unterlassene Prüfung im Raum.

Einordnung

Das Muster ist bekannt: eine vorauthentifizierte Schwachstelle in einer Anwendung am Perimeter, ausgenutzt, bevor ein Patch existierte. Was diesen Fall von anderen unterscheidet, ist die Kombination aus maximaler Bewertung, breiter Installationsbasis im Mittelstand und einem Zeitfenster, das jeder erreichbare Shop durchlaufen hat.

Patchen ist der erste Schritt. Der zweite ist die Frage, was in den drei Tagen davor passiert ist.