9.1 ist der höchste CVSS-Score, den Adobe in diesem Jahr vergeben hat – und trotzdem ist er nicht das eigentliche Problem. Das Problem heißt StyleSmuggler, wird seit dem 4. September aktiv ausgenutzt, braucht keinen Login und hat Stand heute keinen offiziellen Patch. Für jeden Händler, der auf Magento Open Source oder Adobe Commerce läuft, ist das keine Sicherheitsmeldung unter vielen. Es ist die Art Lücke, für die man das Wochenende opfert.
Entdeckt hat sie Sansec, die niederländische Firma, die seit Jahren praktisch im Alleingang das Threat-Intelligence-Geschäft für Magento macht. Die Angreifer waren schneller als jede Verteidigung: Zwischen dem ersten beobachteten Angriff und den ersten funktionierenden Schutzregeln lagen knapp acht Stunden. In genau diesem Fenster wurden die beiden dokumentierten Opfershops kompromittiert – einer davon auf dem neuesten Patchlevel, das Adobe für seine Versionslinie überhaupt anbietet.
Das achtstündige Fenster, in dem nichts half
Die Beweislage ist diesmal ungewöhnlich gut, weil ein Hoster mitten drin saß. Die Disrex Group, ein Magento-Spezialist, der kompromittierte Shops auf eigener Infrastruktur hostet, hat seine Incident-Response öffentlich dokumentiert. Store A lief auf Magento Open Source 2.4.8 und war Sansec-Shield-Kunde – installiert, lizenziert, aktiv. Getroffen wurde er um 23:10 Uhr UTC, Stunden bevor die ersten Blockierregeln existierten. Store B lief acht Patchlevel zurück, war aber innerhalb desselben Zeitfensters dran.
„Patch status was irrelevant here, which is the part merchants most need to hear“ – der Patchstand war irrelevant, und genau das müssen Händler hören, sagt Disrex gegenüber The Hacker News. Der Satz verdreht die übliche Sicherheitslitanei. Sonst heißt es immer: Haltet eure Shops aktuell. Hier hilft das nichts. Beide Shops waren am selben Tag eingedämmt, ohne nachweisbare Datenexfiltration, ohne Zahlungs-Skimmer, ohne neue Admin-Konten. Das war Glück plus gute Infrastruktur: isolierte Accounts, keine Sudo-Rechte, kein Weg zu anderen Kunden.
Wer das liest und bei sich Shared-Hosting-Strukturen von 2018 im Kopf hat, sollte unruhig werden. Der Implantat-Prozess tarnt sich als Linux-Kernel-Thread namens [kworker/u:8:0], installiert sich unter ~/.local/share/.gvfsd/ im Home-Verzeichnis – nicht im Webroot, wo die meisten Scanner suchen – und schreibt sich per Cron alle fünf Minuten neu. Auf einem der Opfer stand dieselbe Cron-Zeile 1.728 Mal. Der Prozess fügte sie innerhalb einer Sekunde nach dem Löschen wieder hinzu.
Wie funktioniert der StyleSmuggler-Angriff?
Der Angriff läuft in zwei Stufen, und beide nutzen legitime Magento-Funktionen gegen den Shop selbst. Zuerst schmuggelt der Angreifer PHP-Code in eine Datei, die Magento im Normalbetrieb selbst schreibt – etwa einen Failure-Report oder das System-Log. Dann löst er die Standard-Mail „Payment Transaction Failed Reminder“ aus. Beim Rendern dieser Mail führt Magento die vergiftete Datei aus. Niemand muss die Mail öffnen, die Zustellung darf sogar scheitern – der Schaden passiert beim Generieren.
Das ist kein dreckiger Hack, sondern eine saubere, unauthentifizierte Remote-Code-Execution-Kette. Sansec hat sie auf sauberen Installationen von Magento 2.4.7, 2.4.8 und 2.4.9 reproduziert. Das eigentliche Implantat ist eine statisch gelinkte Rust-Binary von rund 1,9 Megabyte, gebaut für x86-64 und ARM64. Wer auf einem seiner Server einen bracketierten Prozessnamen mit echtem Speicherverbrauch unter einem normalen Site-User findet, hat ein Problem – echte Kernel-Threads gehören root und belegen keinen Resident Memory.
Ein Detail verdient Aufmerksamkeit: Auf einem der beiden Disrex-Shops baute das Implantat überhaupt keine ausgehende Verbindung auf. Es hielt 28 Verbindungen zur lokalen Redis-Instanz und las daraus Magentos Session-Storage. Sprich: Kundensessions, Warenkörbe, unter Umständen eingeloggte Admin-Sessions. Keine Firewall der Welt sieht das, weil nichts den Server verlässt.
Warum warnt gerade eine kaputte E-Mail vor dem Einbruch?
Die vielleicht wertvollste Erkenntnis der Woche kostet keine Software und kein Budget. Einer der Disrex-Shops wurde durch eine E-Mail enttarnt, die der Shop an seinen eigenen Betreiber schickte: eine Failed-Transaction-Benachrichtigung voller unaufgelöster Template-Variablen, {{var ...}}-Tags im Rohzustand, eine Kundenadresse auf einer .invalid-Domain, Bestellsumme null. Sieht aus wie eine defekte Bestellung. Ist in Wahrheit der Auspuff des Exploits, der durch Magentos Template-Filter gejagt wurde.
Der Händler leitete diese seltsame Mail weiter – und die Untersuchung fand das Implantat innerhalb einer Stunde. Das ist der beste Early-Warning-Mechanismus, den es derzeit gibt, und er braucht keinerlei Tooling.
Wer einen Magento-Shop betreibt, sollte also ab sofort genau diese Mails lesen statt sie wegzuklicken: „Payment Transaction Failed Reminder“ mit Roh-Template-Tags, Null-Summe, Müll-Adressen. Dazu zwei Dateisystem-Checks: var/report/ und var/log/system.log nach Markern der Form X-TRACE- durchsuchen – wobei die Angreifer den Marker schon variiert haben, also nach dem Muster suchen, nicht nach der exakten Zeichenkette. Und einen TypeError von array_merge() mit Integer-Argument im System-Log ernst nehmen: direkt nach dem Include ist das ein Beleg für erfolgreiche Ausführung.
Was bedeutet die Lücke für Händler im DACH-Markt?
Magento hat im deutschen Mittelstand eine Stammkundschaft, die Shopify nie erreicht hat: Erbstück-Shops mit komplexen B2B-Preislogiken, Eigenerweiterungen und einem Integrationspartner, der seit 2017 das Deployment macht. Genau diese Installationen sind das Risiko – nicht weil sie alt sind, sondern weil ihre Update-Zyklen in Wochen gemessen werden und ihre Incident-Response aus einem Anruf bei der Agentur besteht.
Die unbequeme Wahrheit: Deutsche Hoster und Agenturen stehen jetzt vor einer Entscheidung mit zwei schlechten Optionen. Sansecs Interim-Empfehlung lautet, GraphQL temporär abzuschalten, bis Adobe liefert. Das funktioniert für klassische Storefronts und die meisten Hyvä-Setups – Hyvä ist im DACH-Raum inzwischen der De-facto-Standard für Magento-Frontend-Neubauten, und dort kommt der Checkout ohne GraphQL aus. Wer dagegen headless unterwegs ist, PWA-Studio oder eine Composable-Architektur fährt, dem schaltet diese Empfehlung den Shop ab. Dann heißt es: inoffizielle Patches aus der Community prüfen oder hoffen, dass Adobes Security-Release vom 8. September die Lücke abdeckt.
Drei konkrete Härtungsschritte funktionieren unabhängig von der genauen Exploit-Kette und gehören ohnehin auf jede Magento-Härtungsliste:
proc_open(und die übrigen Prozess-Funktionen) in PHPsdisable_functionsaufnehmen – genau darüber startete der Dropper sein Implantat/tmp,/var/tmpund/dev/shmmitnoexecmounten, damit heruntergeladene Binaries nicht laufen- Scan-Pfade erweitern: Der Disrex-Scanner meldete einen kompromittierten Shop elf Stunden lang als sauber, weil er nur den Document Root prüfte – das Implantat lag ein Verzeichnis darüber
Und wer haftet, wenn der Shop schon drin ist?
Kurzer DSGVO-Einschub, weil er im deutschen Kontext unausweichlich ist: Wer Session-Daten und Kundenstämme verliert, hat eine Meldepflicht innerhalb von 72 Stunden. Bei einem Implantat, das Redis-Sessions ausliest, lässt sich schwer argumentieren, dass keine personenbezogenen Daten betroffen sind. Die Aufräum-Reihenfolge von Disrex sollte deshalb jeder Betreiber parat haben, bevor er sie braucht: Erst Beweise sichern, dann den Cron-Eintrag löschen (der Prozess stellt ihn sonst sofort wieder her), nicht rebooten (die einzige verbliebene Binary kann unter /proc liegen), kein composer install zur „Bereinigung“ (das überschreibt die Timestamps, die zeigen, was angefasst wurde). Danach: Session-Storage flushen, den crypt/key in app/etc/env.php rotieren, jedes Admin-Passwort, jeden Payment-Provider-API-Key, jede Integrations-Credential.
Die eigentliche Lehre der Woche ist ungemütlich für Adobe. Ein Zero-Day mit öffentlicher Exploitation, fünf Tage lang kein Advisory, kein CVE, kein Workaround vom Hersteller – währenddessen schreiben ein niederländischer Sicherheitsanbieter, ein Hoster und Community-Entwickler wie Lucas van Staden die eigentliche Verteidigung. Zwei unabhängige Parteien kamen dabei auf demselben Tag auf identische Patches für dieselben drei Scanner-Methoden. Das ist Open Source von seiner besten Seite und Enterprise-Support von seiner schlechtesten.
Wer Magento oder Adobe Commerce betreibt, sollte die GraphQL-Frage heute klären, die Log-Verzeichnisse morgen durchsuchen und die Härtungsschritte diese Woche einspielen. Und wer schon immer wissen wollte, ob sein Monitoring funktioniert: Eine Mail mit rohen {{var}}-Tags und einer .invalid-Adresse ist der günstigste Penetrationstest des Jahres.