StyleSmuggler (CVE-2026-75650): Adobe-Notfall-Patch ist da

Am 4. September 2026 um 22:20 UTC wurde der erste bestätigte StyleSmuggler-Angriff auf einen Magento-Shop registriert. Das niederländische Security-Team von Sansec hat die Kampagne 20 Minuten später erkannt, am 5. September öffentlich gemacht und dem Angriff seinen Namen gegeben. Was daran ungewöhnlich ist: Das erste bestätigte Opfer lief auf Magento 2.4.6-p15 mit allen Security-Patches bis August 2026 — dem höchstmöglichen Patchstand dieser Release-Linie.

Update vom 8. September 2026: Adobe hat am 7. September 2026 um 20:20 UTC — 22:20 Uhr MESZ, für den DACH-Raum also in der Nacht auf den 8. September — außer der Reihe reagiert und mit dem Bulletin APSB26-146 den Hotfix VULN-39341 veröffentlicht. Damit kam der Fix einen Tag vor dem regulären Bulletin-Termin am 8. September. Die Lücke heißt jetzt CVE-2026-75650, ist mit CVSS 10.0 bewertet und trägt Adobe-Priority 1 — die höchste Dringlichkeitsstufe. Adobe bestätigt darin ausdrücklich die aktive Ausnutzung.

Dieser Artikel ist entsprechend aktualisiert und in vier Schritte gegliedert: Hotfix einspielen, auf Kompromittierung prüfen, Zugangsdaten rotieren, zusätzlich härten. Dazwischen steht unverändert die technische Analyse der Angriffskette.

Schritt 1: Hotfix VULN-39341 einspielen

Der Patch ist die einzige echte Behebung. Alles, was in diesem Artikel vorher als Notfall-Mitigation stand, ist damit zur zweiten Verteidigungslinie geworden — nicht mehr zum Ersatz.

Bulletin	APSB26-146, außerplanmäßig veröffentlicht am 7. September 2026, 20:20 UTC (22:20 MESZ)
CVE	CVE-2026-75650
Schweregrad	Critical
CVSS v3.1	10.0 — CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H
Adobe-Priority	1 — Adobe empfiehlt die Installation binnen 72 Stunden
Schwachstellenklasse	CWE-1336 — Improper Neutralization of Special Elements Used in a Template Engine
Patch	VULN-39341_Hotfix_COMPOSER.patch

Download: https://repo.magento.com/patch/VULN-39341-composer-patches.zip

Das Archiv entpacken und den enthaltenen Composer-Patch nach Adobes Standardverfahren für bereitgestellte Composer-Patches einspielen. Anschließend prüfen, ob der Patch wirklich sitzt:

# Setzt das Quality Patches Tool voraus
vendor/bin/magento-patches -n status | grep "39341\|Status"

Erwartet wird eine Zeile mit Status Applied und Patch type: Custom.

Von Adobe getestete Zielversionen — der Hotfix ist ausschließlich gegen die August-2026-Releases verifiziert:

Produkt	Getestete Versionen
Adobe Commerce	2.4.9-2026-aug, 2.4.8-2026-aug, 2.4.7-2026-aug, 2.4.6-2026-aug, 2.4.5-2026-aug, 2.4.4-2026-aug
Adobe Commerce B2B	1.5.3-2026-aug, 1.5.2-2026-aug, 1.4.2-2026-aug, 1.3.4-2026-aug, 1.3.3-2026-aug
Magento Open Source	2.4.9-2026-aug, 2.4.8-2026-aug, 2.4.7-2026-aug, 2.4.6-2026-aug

Betroffen sind laut Adobe jeweils diese Versionen und alle älteren. Zwei Punkte, die in der Praxis auffallen:

• Magento Open Source 2.4.5 und 2.4.4 fehlen in der Liste — sie sind End-of-Life und bekommen keinen getesteten Hotfix. Wer dort noch läuft, hat kein reguläres Update-Ziel und braucht einen Migrationsplan, siehe End-of-Life-Aktionsplan für 2.4.6.
• Adobe schreibt, der Patch könne auf anderen unterstützten Versionen funktionieren, das sei aber nicht offiziell verifiziert. Auf abweichenden Ständen also unbedingt zuerst auf Staging einspielen und setup:di:compile sowie einen Smoke-Test durch Checkout und Admin fahren.

Was StyleSmuggler technisch macht

StyleSmuggler ist eine unauthentifizierte Remote-Code-Execution-Kette — der Angreifer braucht keinen Account, keinen Admin-Zugang, keine Interaktion eines Nutzers. Die Kette läuft in zwei Stufen:

Stufe 1 — Injection. Der Angreifer schleust PHP-Code über die styles-Properties in Magentos Template-Verarbeitung ein und umgeht damit die vorhandenen Schutzmechanismen. Magento schreibt den Payload anschließend selbst in eine Datei, auf die die Applikation Zugriff hat — typischerweise unter var/report/ oder in var/log/system.log.

Stufe 2 — Execution. Der eingeschleuste Code kommt zur Ausführung, wenn Magento eine Benachrichtigung über eine fehlgeschlagene Zahlung rendert. Die Angreifer triggern dafür gezielt den Standard-Mechanismus „Payment Transaction Failed Reminder”. Ausgeführt wird beim Rendern — die Mail muss dafür gar nicht zugestellt werden. Beteiligt sind Methoden der Dependency-Injection-Scanner, die vergiftete Dateien per include bzw. require_once einbinden; PHP parst und führt dann alles aus, was an PHP-Code darin steht.

Das Ergebnis ist eine persistente Backdoor auf dem Shop-Server. Sansec beschreibt das Implant als in Rust kompilierte, gestrippte Binary (rund 1,9 MB, x86-64 und arm64), die sich als Linux-Kernel-Thread tarnt, sich alle 60 Sekunden mit System-Telemetrie beim C2-Server meldet — und ihren Cron-Eintrag innerhalb von Sekunden nach dem Löschen wieder neu setzt.

Betroffene Versionen und Zeitleiste

Version	Status
2.4.6-p15 (inkl. Juli-/August-Patches 2026)	Erstes bestätigtes Opfer
2.4.7	Angriffskette von Sansec auf Clean-Install reproduziert
2.4.8	Angriffskette von Sansec auf Clean-Install reproduziert
2.4.9 (aktuelles Release)	Angriffskette von Sansec auf Clean-Install reproduziert

Adobe hat diese Einschätzung mit APSB26-146 bestätigt: betroffen sind alle Linien von 2.4.4 bis 2.4.9 sowie Adobe Commerce B2B, jeweils inklusive aller älteren Stände. Die praktische Konsequenz für die Tage vor dem 7. September: Ein aktueller Patchstand war hier keine Verteidigung. Wer sein Magento sauber aktuell hält, war bei StyleSmuggler genauso exponiert — der Schutz beginnt erst mit dem Hotfix VULN-39341.

Zeitleiste der Kampagne

Zeitpunkt (UTC)	Ereignis
04.09.2026, 22:20	Erster bestätigter StyleSmuggler-Angriff
04.09.2026, 22:40	Sansec erkennt die Kampagne
04.09.2026, 23:10	Kompromittierung eines von Disrex betreuten Servers
05.09.2026, 07:15	Erste Erkennungsregeln verfügbar
05.09.2026, 13:51	Kompromittierung bei der Incident Response bestätigt
06.09.2026	Neue Persistenz-Variante identifiziert (fc-cache)
07.09.2026, 20:20	Adobe veröffentlicht außerplanmäßig APSB26-146 mit dem Hotfix VULN-39341
08.09.2026	Regulärer Bulletin-Termin — der Fix kam einen Tag früher

Zwei Fenster sind hier entscheidend. Zwischen dem ersten Angriff und den ersten verfügbaren Erkennungsregeln lagen rund neun Stunden — in dieser Zeit half kein signaturbasierter Schutz, die zweite dokumentierte Kompromittierung erfolgte bereits 50 Minuten nach Kampagnenstart. Und zwischen dem ersten Angriff und dem Hotfix lagen rund drei Tage, in denen jede erreichbare Installation offen stand. Genau deshalb ersetzt der Patch die Prüfung aus Schritt 2 nicht.

Schritt 2: Prüfen, ob dein Shop kompromittiert ist

Der Patch schließt das Loch — er sagt dir aber nicht, ob vorher schon jemand durch war. Zwischen dem ersten dokumentierten Angriff am 4. September und dem Hotfix am 7. September lagen rund drei Tage. Diese Prüfung ist deshalb kein optionaler Zusatz, sondern der zweite Pflichtschritt. Auf einem bereits übernommenen System hat Incident Response Vorrang vor der Credential-Rotation.

Indikatoren einer Kompromittierung

Von Sansec und Disrex veröffentlichte Indikatoren (Stand 8. September 2026):

Prozesse

• [kworker/u:8:0] unter einem Nicht-root-User (erste Variante)
• fc-cache (Variante vom 6. September)

Dateien und Persistenz

• ~/.local/share/.gvfsd/gvfsd-user plus zugehörige Lock-Dateien
• ~/.cache/fontconfig/fc-cache (fc-cache-Variante)
• Verzeichnisse /tmp/.kw_* und /tmp/.fc_*
• Cron-Einträge mit */5 * * * * bzw. 13,43 * * * *

Netzwerk

• Malware-Hosts: 247.cdnflare[.]xyz, 209.141.43[.]95
• C2: 99.84.67[.]186:443 (WebSocket über TLS), ntp.timesync[.]to:123 (als NTP getarnt), windwsecurity[.]run:443
• POST-Requests auf /graphql?styles[....]=
• Gefälschter User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36

Der unterschätzte Frühindikator: fehlerhaft gerenderte „Payment Transaction Failed”-Mails mit unaufgelösten Template-Variablen. Wenn im Shop-Postfach plötzlich kaputte Zahlungs-Fehlermails auftauchen, ist das für Händler das nützlichste Frühwarnsignal überhaupt — und es erreicht dich nicht über einen Scanner, sondern im Posteingang.

Die Checks

Alle Checks laufen read-only und dauern zusammen keine zwei Minuten.

# Implant-Prozess: eckige Klammern im Namen, aber nicht root
ps -eo pid,user,rss,args --no-headers | awk '$4 ~ /^\[/ && $2 != "root"'

# Persistenz
crontab -l | grep -i gvfsd
ls -la ~/.local/share/.gvfsd/ /tmp/.kw_* /tmp/.gvfsd-* 2>/dev/null

# Stufe 1: vergiftete Dateien im Magento-Root
grep -rl 'X_TRACE_\|<?php' var/report/ var/log/ 2>/dev/null

# Stufe 2: Angriffsversuche im Access-Log
grep -acE 'styles(\[|%5B)|generatorClass|with_resolved|cdnflare' /pfad/zum/access.log

Auf Shared Hosting bzw. Servern mit mehreren Shops zusätzlich als root:

find /home /root /tmp /var/tmp /dev/shm \
  \( -name 'gvfsd-user' -o -name '.gvfsd_*.lock' -o -name '.kw_*' \) 2>/dev/null

Treffer bei den Prozess-, Cron- oder Datei-Checks bedeuten aktive Kompromittierung. Treffer nur im Access-Log bedeuten Angriffsversuche — prüfe dann besonders sorgfältig, ob Stufe 1 erfolgreich war.

Schritt 3: Zugangsdaten rotieren

Adobe ist an diesem Punkt ungewöhnlich deutlich: Patchen allein reicht nicht. Wer die Lücke offen hatte, muss davon ausgehen, dass Zugangsdaten abgeflossen sind — und der Encryption-Key schützt in Magento genau die sensibelsten davon: Integration-Tokens, Payment-Gateway-Credentials und privilegierte Automatisierungs-Tokens.

Entscheidend ist der Punkt, den Adobe explizit macht: Den Encryption-Key zu rotieren entwertet bereits abgeflossene Zugangsdaten nicht. Ein gestohlener Stripe-API-Key funktioniert weiter, egal was in Magento passiert. Solche Credentials müssen an der Quelle rotiert werden — beim Zahlungsanbieter, beim Drittsystem, beim Hoster.

Adobes vorgeschriebene Reihenfolge:

1. Hotfix einspielen
2. Maintenance-Mode aktivieren
3. Cron stoppen (Cloud: vendor/bin/ece-tools cron:disable)
4. Encryption-Keys rotieren
5. Alle Admin-Passwörter zurücksetzen
6. Alle REST-/SOAP-/GraphQL-Integration-Tokens deaktivieren und neu erzeugen (System → Extensions → Integrations)
7. OAuth-Client-Secrets angebundener Drittanwendungen rotieren
8. Payment-Gateway-Credentials beim Anbieter rotieren (Stripe, Braintree, Adyen, PayPal …)
9. Datenbank-Zugangsdaten rotieren
10. SSH-/Deploy-Keys sowie Credentials von Cron- und System-Service-Accounts rotieren
11. API-Keys für Versand-, Steuer- und weitere angebundene Extensions rotieren
12. Cache leeren
13. Cron wieder starten (Cloud: vendor/bin/ece-tools cron:enable)
14. Maintenance-Mode deaktivieren

Aus der Praxis dazu drei Anmerkungen:

• Schritt 6 ist der, der am ehesten Integrationen bricht. ERP-, PIM- und Marktplatz-Anbindungen hängen an diesen Tokens. Vor der Rotation eine Liste aller aktiven Integrationen ziehen und die Gegenstellen im Vorfeld informieren, sonst laufen nach dem Maintenance-Mode stumm die Bestell-Exporte leer.
• Die Key-Rotation ist auf großen Katalogen langlaufend, weil alle verschlüsselten Werte neu geschrieben werden. Auf Produktion nicht ohne Zeitfenster starten, und vorher ein Datenbank-Backup ziehen.
• Bei bestätigter Kompromittierung ist diese Liste die falsche Reihenfolge. Dann gilt der volle Incident-Response-Ablauf: isolieren, Image sichern, neu aufsetzen — und erst auf dem sauberen System patchen und rotieren. Credentials auf einem System zu erneuern, auf dem noch eine Backdoor läuft, erneuert nur, was der Angreifer als Nächstes mitliest.

Schritt 4: Zusätzliche Härtung

Die folgenden Maßnahmen stammen aus der Zeit vor dem Patch. Sie sind kein Ersatz mehr für den Hotfix, aber weiterhin sinnvoll als zweite Verteidigungslinie — insbesondere auf Systemen, auf denen der Patch nicht sofort produktiv gehen kann, oder auf Versionen ohne getesteten Hotfix.

4a — Query-String-Regeln am Webserver

Disrex hat nginx- und Apache-Snippets veröffentlicht, die die beobachteten Request-Muster blocken. Für nginx, innerhalb des jeweiligen server { }-Blocks:

# Der Gadget-Parameter. Keine legitime Magento-Route nutzt ihn.
if ($query_string ~* "styles(\[|%5B)")                                  { return 444; }

# Object-Injection-Driver aus der beobachteten Kette
if ($query_string ~* "(generatorClass|with_resolved)")                  { return 444; }

# Magento-Template-Direktiven im Query-String
if ($query_string ~* "(\{\{|%7B%7B)\s*(block|config|trans|var|depend)") { return 444; }

# Rohes PHP-Open-Tag im Query-String
if ($query_string ~* "(<\?|%3C%3F)")                                    { return 444; }

# Rohes PHP-Open-Tag im User-Agent
if ($http_user_agent ~* "<\?(php|=)")                                   { return 444; }

Vor dem Reload immer nginx -t. Wichtige Einschränkung: Diese Regeln inspizieren ausschließlich den Query-String. Ein Angreifer, der dieselben Parameter in den POST-Body verschiebt, läuft daran vorbei. Das ist eine Bremse, kein Schloss.

4b — DI-Scanner-Methoden auf CLI beschränken

Der wirksamste Eingriff vor dem Patch, und danach weiterhin eine sinnvolle Härtung: Die drei Dependency-Injection-Scanner-Methoden, die als include/require_once-Sink dienen, per PHP_SAPI !== 'cli'-Guard für Web-Requests sperren. Betroffen sind:

• ArrayScanner::collectEntities()
• XmlInterceptorScanner::_handleControllerClassName()
• ClassesScanner::includeClass()

setup:di:compile funktioniert damit weiter. Vorher prüfen, ob Drittanbieter-Module diese Klassen über HTTP aufrufen — das kommt vor und würde durch den Guard brechen. Vergleichbare inoffizielle Patches gibt es von ProxiBlue, Disrex und Graycore. Wer einen davon eingespielt hat, sollte ihn vor dem offiziellen Hotfix zurücknehmen, um Konflikte beim Patchen zu vermeiden.

4c — Angriffsfläche und Ausführungsumgebung verkleinern

• GraphQL kann nach dem Hotfix wieder aktiviert werden. Wer den Endpoint als Notfallmaßnahme abgeschaltet hat, nimmt das nach erfolgreichem Patch und sauberem Indikator-Check zurück — für Shops mit Agentic-Commerce-Anbindung oder PWA-Frontend war das ein echter Funktionsverlust.
• proc_open in disable_functions der PHP-Konfiguration aufnehmen.
• /tmp, /var/tmp und /dev/shm mit noexec mounten.
• Den lokalen Redis-Dienst gegen Zugriffe von außerhalb der Applikation absichern — das Implant hat in dokumentierten Fällen darauf zugegriffen.

Was die Incident-Response-Praxis zeigt

Disrex hat zwei kompromittierte Magento-Open-Source-Shops bearbeitet und die Analyse öffentlich gemacht. Beide waren binnen 11 bis 14 Stunden eingedämmt. In beiden Fällen fanden sich keine Datenexfiltration, keine Payment-Skimmer und keine angelegten Admin-Accounts — die Angreifer haben es (bisher) auf dauerhaften Serverzugriff abgesehen, nicht auf Kartendaten. Über beide Vorfälle hinweg wurden 26 verschiedene Angreifer-Quelladressen identifiziert.

Bemerkenswert: Einer der beiden Shops lief auf 2.4.8 und hatte kommerziellen Malware-Schutz aktiv — die Kompromittierung erfolgte trotzdem, weil sie vor der Veröffentlichung der ersten Erkennungsregeln stattfand. Bei einem Zero-Day dieser Art gilt eben: Signatur-basierter Schutz beginnt erst zu greifen, wenn jemand die Signatur geschrieben hat.

Wie viele Shops insgesamt betroffen sind, hat Sansec nicht veröffentlicht. Kursierende Zahlen in Sekundärquellen sind nicht belegt — verlass dich auf deine eigenen Log-Checks, nicht auf Schätzungen.

Unsere Einschätzung

Drei Punkte, die wir Kunden diese Woche so kommunizieren:

Erstens: Der Patch beendet die Angriffe, nicht den Vorfall. Der übliche Reflex nach einem Hotfix — „eingespielt, Thema erledigt” — trägt hier nicht. Die Lücke stand drei Tage offen, und das Implant überlebt jedes Update. Prüfe die Indikatoren, unabhängig von Version und Patchstand.

Zweitens: Log-Retention entscheidet über die Aufklärbarkeit. Wenn deine Access-Logs nur sieben Tage vorgehalten werden, ist das Zeitfenster ab dem 4. September bald weg. Sichere die Logs jetzt weg, bevor die Rotation sie überschreibt — auch wenn du aktuell keinen Treffer hast.

Drittens: Patchen ist keine Bereinigung. Wenn das Implant läuft, hilft weder Webserver-Regelwerk noch Hotfix — die Backdoor sitzt außerhalb des Applikationscodes und überlebt jedes Composer-Update. Dann gilt der volle Incident-Response-Ablauf: isolieren, Image sichern, aus verifiziert sauberer Quelle neu aufsetzen, und erst dort die Credentials rotieren. Alles andere ist Symptombehandlung an einem Prozess, der sich alle fünf Minuten selbst neu startet.

Wir aktualisieren diesen Artikel weiter, sobald sich am Erkenntnisstand etwas Wesentliches ändert.

Was du als Nächstes tun kannst

Wenn du unsicher bist, ob dein Shop in den drei offenen Tagen erwischt wurde, oder den Hotfix samt Credential-Rotation nicht selbst fahren willst: Wir spielen VULN-39341 kontrolliert über Staging auf Produktion, prüfen deine Umgebung auf die bekannten Indikatoren, sichern die Logs und begleiten die Rotation inklusive Abstimmung mit deinen angebundenen Systemen — im Rahmen von Magento-Sicherheit und laufender Betreuung. Kontakt: Security-Check anfragen oder per Mail an office@copex.io.

Verwandte Themen aus unserem Blog: Wie sicher ist mein Magento-Onlineshop?, Sicheres Update- und Patch-Management für Magento, Häufigste Sicherheitslücken bei Magento-Shops, Magento 2.4.6 End-of-Life: Aktionsplan.

Quellen / Weiterlesen

• Adobe — Kritisches Security-Update für Adobe Commerce (APSB26-146), inkl. Patch-Download und Rotations-Checkliste
• Adobe Security Bulletin APSB26-146 (CVE-2026-75650)
• Sansec — StyleSmuggler: Magento and Adobe Commerce 0-day RCE under active attack
• Disrex — StyleSmuggler Magento Zero-Day (Incident-Response-Analyse)
• disrex-group/stylesmuggler-mitigation — Notfall-Mitigation auf GitHub
• The Hacker News — Unpatched Magento and Adobe Commerce Zero-Day Exploited to Backdoor Online Stores
• Adobe — Security Bulletins and Advisories für Magento / Adobe Commerce