stylesmuggler-ioc-toolkit

StyleSmuggler (CVE-2026-75650) IOC-Toolkit für Magento Open Source und Adobe Commerce. Erkennen Sie kompromittierte Shops, Rust-Implantate, PHP-Webshells, Persistenz-Artefakte und bekannte Indikatoren für eine Kompromittierung.

Offizielle Patch-Abdeckung von Adobe — prüfen Sie dies, bevor Sie annehmen, dass Sie sicher sind

Wenn Sie eine ältere, nicht unterstützte Version verwenden, liefert Adobe Ihnen keinen Fix, obwohl Sie genauso angreifbar sind. Siehe docs/PATCHING.md für Ihre Optionen.

Diese Informationen ändern sich schnell. Überprüfen Sie vor dem Handeln die Primärquellen: Sansecs Advisory und Adobes Bulletin. Siehe docs/TIMELINE.md für ein laufendes Protokoll und zitieren Sie Ihre Quellen, wenn Sie hier etwas aktualisieren.

Was StyleSmuggler tatsächlich ist

Magentos eigener GraphQL-styles-Parameter und sein auf Dependency-Injection basierender Datei-Scanner werden als zweistufige, dateibasierte Deferred-Execution-Primitive missbraucht, anstatt als einzelner offensichtlicher Injektionspunkt:

1. Vergiften. Angreifer-kontrollierte Daten erreichen eine von Magento generierte Log- oder Report-Datei (var/log/system.log über einen ungültigen Store-Code, den Magento wörtlich protokolliert, oder var/report/<hash>), eingeschmuggelt über den GraphQL-styles[]-Parameter, einen mutierten Request-Header oder (für den zweiten, nicht verwandten Angreifer unten) den Store:-Header.
2. Zünden. Der Angreifer löst Magentos standardmäßige „Payment Transaction Failed Reminder“-E-Mail aus. Das Rendern dieser E-Mail (Magentos getProcessedTemplate-Pfad) durchläuft einen Codepfad, der es Magentos eigenem DI-/Code-Scanner ermöglicht, die vergiftete Datei per include() einzubinden und so das PHP des Angreifers auszuführen. Sie müssen die E-Mail nicht öffnen — das serverseitige Rendern reicht aus — und die Kette kann sogar dann ausgelöst werden, wenn die E-Mail-Zustellung selbst fehlschlägt.

Ein einfaches, werkzeugloses Frühwarnzeichen: eine verstümmelte „Payment Transaction Failed Reminder“-E-Mail in Ihrem Posteingang mit rohen, ungerenderten {{var ...}}-Tags und einer Kundenadresse, die auf .invalid endet. Dies ist oft das erste sichtbare Zeichen, bevor jemand ein Log prüft.

Sansecs Updates bestätigten einen zweiten, unabhängigen Ausnutzungspfad für dieselbe Rust-Implantat-Kampagne: Selbst Stores, die die Session-Speicherung von Redis auf die Datenbank verlagert hatten, wurden weiterhin kompromittiert — der zweite Versuch desselben Betreibers gelang Sekunden später über eine Datei, die über Magentos Kunden-Custom-Options-Funktion hochgeladen wurde. Die Verlagerung der Session-Speicherung ist für sich genommen kein Fix.

Separat fand Sansec am 7. September einen völlig unabhängigen Angreifer, der denselben StyleSmuggler-Einstiegspunkt für eine viel einfachere Payload nutzte: eine PHP-Webshell, die in Magentos eigenen Produktbild-Cache abgelegt wurde (pub/media/catalog/product/cache/ss_<10hex>/sync_<10hex>.php), eingeleitet durch eine Aufklärungs-Sonde, die ihre Payload im Store:-HTTP-Header versteckt und ihre Ergebnisse über DNS statt über eine HTTP-Antwort exfiltriert. Laut Sansec handelt es sich um „Standard-Tooling“ — keine anhaltende Kampagne — aber es bedeutet, dass ein einzelner verwundbarer Host zwei unabhängige Eindringlinge über eine einzige Schwachstelle tragen kann. Die Bereinigung des Rust-Implantats bedeutet nicht, dass Ihr Store sauber ist.

Das Rust-Implantat selbst hat sich ebenfalls weiterentwickelt: Auf den ursprünglichen, als [kworker/u:8:0] getarnten Build (4. Sept.) folgte ein als fc-cache getarnter Build v2.1.4 (6. Sept.), der als NTP-Verkehr getarnt Beacon-Signale sendet, und dann eine als chronyd getarnte Neubereitstellung v2.1.5 (7. Sept.) desselben Implantats, derselben Agenten-ID — ein Beweis dafür, dass der Angreifer aktiv iteriert, um Ihrer veröffentlichten Erkennung zu entgehen. Sansec gibt an, bisher keine Hinweise darauf gesehen zu haben, dass dieses Implantat über Persistenz/Aufklärung hinaus bewaffnet wurde — lesen Sie das angesichts der funktionierenden Webshell des unabhängigen Angreifers auf demselben Zugriffspfad nicht als Beruhigung.

Siehe docs/FAQ.md für schnelle Antworten, docs/VULNERABILITY.md für die vollständige technische Dokumentation und Quellenangaben, docs/PATCHING.md für die Anwendung von Adobes offiziellem Fix und docs/INCIDENT_RESPONSE.md für das Vorgehen, wenn der Scanner etwas findet.

Schnellstart

1. Patchen, falls Ihre Version abgedeckt ist:

2. Unabhängig vom Patch-Status auf bestehende Kompromittierung scannen — Patchen stoppt neue Ausnutzung, bereinigt aber kein bestehendes Backdoor oder eine Webshell:

Oder die Python-Version für strukturierte (JSON-)Ausgabe, z. B. zur Einspeisung in ein SIEM:

Beide Skripte sind standardmäßig schreibgeschützt — sie erkennen und melden, sie beenden keine Prozesse und löschen keine Dateien, es sei denn, Sie übergeben --remediate, da eine verfrühte Bereinigung forensische Beweise zerstört (siehe docs/INCIDENT_RESPONSE.md).

Was der Scanner prüft

• Bekannte Dateisystem-Persistenz-Artefakte aller drei beobachteten Rust-Implantat-Builds:
  • [kworker/u:8:0]-Build: ~/.local/share/.gvfsd/gvfsd-user, dessen Sperrdateien, /tmp/.kw_*, /tmp/.gvfsd_*
  • fc-cache-Build v2.1.4 (6. Sept.): ~/.cache/fontconfig/fc-cache, /tmp/.fc_<8hex>.lock
  • chronyd-Build v2.1.5 (7. Sept.): /tmp/.chrony-<8hex>/chronyd
• Die selbstwiederherstellenden Crontab-Einträge, die das Implantat direkt in den Cron-Spool schreibt — alle 5 Minuten für den gvfsd-user-Build, zweimal pro Stunde (13,43 * * * *) für fc-cache
• Einen getarnten Prozess namens [kworker/u:8:0], fc-cache oder chronyd, der nicht root gehört (oder, für fc-cache/chronyd, nicht mit dem echten System-Binary übereinstimmt)
• SHA-256 der Binärdateien auf der Festplatte und des Live-/proc/<pid>/exe-Images (die beiden können sich unterscheiden — das Implantat wurde dabei beobachtet, wie es sich im Speicher selbst aktualisiert)
• Vergiftete Log-/Report-Dateien (var/log/system.log, var/report/) auf injiziertes PHP, die beiden bekannten Trigger-Header-Formen (X-TRACE-<10hex> und X-<12hex>) sowie die Kampagnen-Marker des zweiten, nicht verwandten Angreifers (ss5_/ss6_<hex>) und die DNS-Canary-Domain (oast.site)
• Proof-of-Execution-Antwortmarker (MG<20hex>::...::/MG<20hex>), die in Logs zurückbleiben, wenn die Payload tatsächlich ausgeführt wurde
• PHP-Dateien unter pub/media — die auf einem korrekt konfigurierten Magento-Store niemals ausführbares PHP enthalten sollten — die dem Webshell-Ablegemuster des zweiten Angreifers entsprechen
• Bestehende Verbindungen zu den veröffentlichten C2-/Download-Hosts — einschließlich des NTP-förmigen Beaconings des fc-cache/chronyd-Builds an ntp.timesync.to:123/UDP (und Fallbacks) sowie seiner einfachen HTTP-Aufrufe an öffentliche IP-Lookup-Dienste
• Anomale lokale Redis-Verbindungszahlen (Session-Ernte wurde vollständig über 127.0.0.1:6379 beobachtet, mit null ausgehendem C2-Verkehr — ein ruhiges Netzwerk ist kein sauberes) — und beachten Sie, dass die alleinige Verlagerung von Sessions von Redis den zweiten, datei-Upload-basierten Ausnutzungsvektor nicht schließt

Vollständige Indikatorliste mit Quellenangaben: iocs/.

Patchen und Abschwächung

1. Adobes offiziellen Hotfix (VULN-39341 / APSB26-146) anwenden, falls Ihre Version abgedeckt ist — siehe docs/PATCHING.md für Kennungen, Bezugsquellen und Anwendung. Dies hat nun Priorität vor den untenstehenden Übergangsmaßnahmen.
2. Wenn Sie nicht sofort patchen können oder Ihre Version nicht abgedeckt ist, verwenden Sie die Übergangsmaßnahmen in mitigations/:
   • Blockieren oder Ratenbegrenzen des GraphQL-styles[]-Zustellpfads (nginx / Apache)
   • Blockieren der PHP-Ausführung unter pub/media/pub/static (nginx / Apache) — gezielte Verteidigung gegen die Webshell-Technik des zweiten, nicht verwandten Angreifers
   • ModSecurity-Regeln für die POST-Body-Inspektion und fail2ban als reaktive Absicherung
   • Siehe mitigations/README.md für Einschränkungen des Umfangs — keine dieser Maßnahmen schließt den Customer-Custom-Options-Vektor oder die Store:-Header-Zustellung des zweiten Angreifers.
3. Den Kompromittierungs-Scanner unabhängig vom Patch-/Abschwächungsstatus ausführen. Patchen und Abschwächen stoppen neue Ausnutzung; beides bereinigt kein bereits abgelegtes Backdoor oder eine Webshell.
4. Wenn der Scanner etwas findet, behandeln Sie den Host als vollständig kompromittiert, nicht nur als „Backdoor vorhanden“. Code-Ausführung als Site-Benutzer legt alles offen, was dieser Benutzer lesen kann, beginnend mit app/etc/env.php. Mindestens nach der Eindämmung: Session-Speicher leeren (Redis und/oder DB), den Magento-crypt/key rotieren, alle Admin-Passwörter (und bestehende Admin-Sessions invalidieren), das Datenbank-Passwort, jeden Payment-Provider-API-Key und andere Integrations-Anmeldeinformationen in env.php sowie alle SSH-/Deploy-Keys, die der Site-Benutzer lesen konnte. Prüfen Sie außerdem die admin_user-Tabelle auf ein betrügerisches Konto und pub/media/ / pub/static/ / Theme-Verzeichnisse auf abgelegte Webshells — sowohl die des Rust-Implantats als auch die des nicht verwandten zweiten Angreifers — bevor Sie einen Store als sauber betrachten. Vollständige Reihenfolge der Schritte: docs/INCIDENT_RESPONSE.md.

Repository-Struktur

Häufig gesuchte Begriffe

CVE-2026-75650, APSB26-146, VULN-39341, Magento Zero-Day 2026, Adobe Commerce Zero-Day, StyleSmuggler-Patch, Magento-GraphQL-Schwachstelle, Magento-Styles-Parameter-RCE, gvfsd-user-Malware, fc-cache-Magento-Backdoor, chronyd-Magento-Malware, Magento-kworker-Prozess-Malware, Magento-Redis-Session-Hijack, Magento-unauthentifizierte-RCE-September-2026, Magento-2.4.9-Exploit, Adobe-Commerce-Backdoor-Entfernung, Magento-pub-media-Webshell, eComscan-StyleSmuggler, Sansec-Shield-StyleSmuggler.

Quellen und Herkunft

Jeder Indikator in diesem Repository geht auf eine zitierte, veröffentlichte Quelle zurück — in erster Linie Sansecs Advisory (mindestens bis 07.09.2026 20:50 UTC aktualisiert), Adobes APSB26-146-Bulletin sowie Community-Incident-Response-Berichte von Respondern, die Live-Infektionen behandelt haben. Siehe die Quellenangabe am Ende jeder Datei in iocs/.

Behandeln Sie nichts hier als vollständig oder endgültig. IOCs (Trigger-Header, User-Agent-Strings, Implantat-Tarnungen und nun auch die Kampagnen-Marker eines zweiten Angreifers) haben sich bereits innerhalb von Tagen nach der Offenlegung mehrfach geändert; rechnen Sie mit weiteren Änderungen. Gleichen Sie Formen und Verhalten ab, nicht nur wörtliche Strings, wo immer es die Skripte zulassen.

Mitwirken

Eine Variante, einen neuen Hash, eine neue Quelladresse oder einen False Positive gesehen? Eröffnen Sie ein Issue oder einen PR mit dem, was Sie beobachtet haben, und wie Sie es beobachtet haben. Bitte:

• Entfernen Sie die identifizierenden Details Ihrer eigenen Organisation, bevor Sie teilen.
• Veröffentlichen Sie hier keine Exploit-Payloads oder funktionierende Trigger-Requests — nur Indikatoren und Erkennungslogik.
• Melden Sie die zugrunde liegende Schwachstelle selbst an Sansec und Adobe PSIRT, nicht an dieses Repository.

Lizenz

MIT für den Code in diesem Repository (siehe LICENSE). Indikatordaten werden „wie besehen“ für defensive Zwecke bereitgestellt, mit durchgehenden Quellenangaben.

Haftungsausschluss

Dies ist inoffizielles, von der Community erstelltes defensives Tooling, kein Adobe- oder Sansec-Produkt und mit keinem von beiden verbunden. Es wird ohne Gewähr bereitgestellt. Adobes offizieller Patch (APSB26-146) wurde veröffentlicht, aber die Abdeckung ist auf bestimmte Produktversionen beschränkt — prüfen Sie Adobes Sicherheitsbulletin direkt, bevor Sie annehmen, dass Ihre Installation abgedeckt oder behoben ist.