23:10 Uhr UTC, 4. September 2026. Zu dieser Minute fällt der erste Magento-Shop, von dem wir wissen, dass er fiel. Vollständig gepatcht, Sicherheitsmodul aktiv, alle Updates von Juli und August installiert. Acht Stunden später existierte überhaupt erst eine Abwehr gegen den Angriff. Für diesen Shop kam sie zu spät.
Der Zero-Day trägt den Namen StyleSmuggler, entdeckt hat ihn das niederländische Sicherheitsunternehmen Sansec. Betroffen sind Magento Open Source und Adobe Commerce in allen aktuellen Versionen — Sansec hat die komplette Angriffskette auf sauberen Installationen von 2.4.7, 2.4.8 und 2.4.9 reproduziert. Wer diesen Monat ein Magento-System betreibt, betreibt ein System mit einer offenen Tür, für die Adobe bis zum Redaktionsschluss weder Patch noch CVE-Nummer noch offizielle Warnung veröffentlicht hat.
Das ist der unangenehme Kern dieser Geschichte: Der Patch-Stand ist irrelevant. Das erste bekannte Opfer lief auf 2.4.6-p15, dem höchsten Patch-Level, das Adobe für diese Versionslinie überhaupt anbietet. Jeder Händler, der sich auf diszipliniertes Updating als Sicherheitsstrategie verlässt, muss diese Strategie jetzt neu denken.
Was macht StyleSmuggler so gefährlich?
Drei Eigenschaften heben diesen Angriff aus dem üblichen Magento-Vorfällen der letzten Jahre heraus. Erstens braucht er keine Authentifizierung: Der Angreifer benötigt weder Kundenkonto noch Admin-Zugang, er ruft schlicht eine öffentlich erreichbare Schnittstelle auf. Zweitens installiert er einen persistenten Hinterzugang, der Neustarts und Aufräumarbeiten überlebt. Drittens tarnt sich dieser Hinterzugang als Linux-Kernel-Thread — unter dem Namen [kworker/u:8:0], einer Bezeichnung, die jeder Administrator in der Prozessliste schon tausendmal gesehen und ignoriert hat.
Die eigentliche Schadsoftware liegt bewusst außerhalb des Webroots, im Home-Verzeichnis des Shop-Benutzers unter ~/.local/share/.gvfsd/gvfsd-user. Ein Cronjob, direkt in die Spool-Datei unter /var/spool/cron/crontabs/ geschrieben, startet den Prozess alle fünf Minuten neu — ohne dass das Systemprotokoll eine crontab-Änderung verzeichnet. In einem dokumentierten Fall stand diese Zeile 1.728-mal in der Datei; nach dem Löschen trug das Implantat sie binnen einer Sekunde wieder ein.
Besonders aufschlussreich ist das Verhalten nach der Infektion. Auf einem der beiden von der Disrex Group untersuchten Shops baute das Implantat keinerlei Verbindung nach außen auf. Stattdessen hielt es 28 Verbindungen zur eigenen Redis-Instanz offen — und las den Session-Speicher des Shops mit. Kundensessions, Warenkörbe, möglicherweise Admin-Sessions: alles, was Magento in Redis ablegt, lag offen da.
Wie funktioniert der Angriff über die Kassen-E-Mail?
Die Angriffskette ist zweistufig und erschreckend elegant, weil sie ausschließlich Funktionen benutzt, die Magento selbst mitbringt. Zuerst schmuggelt der Angreifer PHP-Code in eine Datei, die Magento im normalen Betrieb selbst schreibt — etwa in var/log/system.log oder in einen Fehlerreport unter var/report/. Dann stößt er die Standard-E-Mail „Payment Transaction Failed Reminder“ an, jene Benachrichtigung über fehlgeschlagene Zahlungen, die jeder Magento-Shop kennt.
Beim Rendern dieser E-Mail führt Magento den eingeschmuggelten Code aus. Niemand muss die Nachricht öffnen. Der Angriff gelingt selbst dann, wenn der Mailversand komplett fehlschlägt — es geht nie um die E-Mail, sondern um die Template-Engine, die sie erzeugt.
Der Angriff reitet auf Funktionen, die kein Shop abschalten kann, ohne sich selbst lahmzulegen. Das ist der Unterschied zwischen einer Lücke und einem Designproblem.
Ausgerechnet diese E-Mail wurde auch zum wichtigsten Frühwarnsignal. Ein Händler leitete dem Disrex-Mitgründer Rick Bouma eine seltsame fehlgeschlagene-Transaktion-Mail weiter: Der Text bestand aus unaufgelösten Template-Variablen wie {{var ...}}, die Kundenadresse endete auf einer .invalid-Domain, die Summe betrug null. Sah aus wie ein defekter Bestellvorgang. War in Wahrheit der Auspuff des Exploits, der durch Magentos Template-Filter gerauscht war. Diese Weiterleitung startete die Untersuchung, die das Implantat binnen einer Stunde fand.
Warum versagen Scanner und Patch-Disziplin hier gleichermaßen?
Der Fall offenbart zwei blinde Flecken der üblichen Magento-Sicherheitsroutine. Der erste betrifft die Werkzeuge: Auf einem der kompromittierten Shops lief Sansecs eigener Scanner eComscan elf Stunden nach der Infektion — und meldete den Shop als sauber, während 1.728 Schad-Cronzeilen aktiv waren. Kein Fehler des Scanners, sondern einer der Reichweite: Der Scan zeigte auf das Document Root, das Implantat saß ein Verzeichnis darüber. Wer nur den Webroot scannt, scannt am Angriff vorbei.
Zweiter blinder Fleck: die Verteidigung am Perimeter. Disrex veröffentlichte nginx- und Apache-Regeln, die Anfragen mit den Exploit-Parametern blockieren — und dokumentierte gleich deren Grenze. Dieselben Parameter im POST-Body oder als JSON erreichten PHP ungehindert, weil Webserver nur den Query-String inspizieren. Die Regeln stoppen die aktuelle Kampagne, nicht die Schwachstelle. Ein Angreifer, der seine Requests umbaut, geht hindurch.
Hinzu kommt die Herkunft des Traffics: Disrex zählte 26 verschiedene Absenderadressen, darunter ein Pool aus Residential-Proxys, der je nur zwei bis sechs Anfragen schickte. Wer die einzelne Angreifer-IP aus Sansecs Warnung blockte, stoppte weniger als ein Viertel des beobachteten Angriffsverkehrs. IP-Blocklisten sind hier Placebo.
Was Magento-Händler jetzt konkret tun müssen
Es gibt keinen Hersteller-Patch. Adobes nächster planmäßiger Security-Release war für den 8. September terminiert; ob er StyleSmuggler abdeckt, ist offen. Bis dahin bleibt ein gestaffeltes Sofortprogramm, das jeder DACH-Shopbetreiber mit seiner Agentur oder seinem Hoster diese Woche abarbeiten sollte:
- GraphQL temporär deaktivieren, wo das Frontend es nicht braucht. Klassische Luma- und Hyvä-Frontends kommen ohne aus — für die hyvä-dominierte deutsche Magento-Szene ist das die schmerzfreiste Sofortmaßnahme. Headless- und PWA-Setups brauchen GraphQL dagegen zwingend und müssen auf die anderen Ebenen ausweichen.
- PHP härten:
proc_openin diedisable_functionsaufnehmen und/tmp,/var/tmpsowie/dev/shmmitnoexecmounten. In einem der dokumentierten Fälle waren vier der sechs Prozess-Funktionen deaktiviert —proc_opennicht, und genau darüber startete der Dropper das Implantat. - Indikatoren prüfen: Prozess
[kworker/u:8:0]unter einem Nicht-Root-Benutzer mit realem Speicherverbrauch, die Datei~/.local/share/.gvfsd/gvfsd-user, fünf-Minuten-Cronjobs im Spool-Verzeichnis, Marker der FormX_TRACE_invar/report/undvar/log/system.log— beide Verzeichnisse, nicht nur eins. - Bei Befund richtig aufräumen: Beweise sichern, Cronjob vor dem Prozess entfernen, nicht neu starten, kein
composer installzur „Reinigung“. Danach Session-Speicher leeren, dencrypt/keyinapp/etc/env.phprotieren, alle Admin-Passwörter und sämtliche API-Schlüssel der Zahlungsanbieter tauschen.
Dazu kommen inoffizielle Patches aus der Community: Disrex, der Entwickler Lucas van Staden (ProxiBlue) und die Agentur Graycore haben unabhängig voneinander Absicherungen veröffentlicht, die Teile der Angriffskette unterbrechen. Bemerkenswert: Disrex und van Staden landeten ohne Absprache bei identischem Code — derselbe Schutz, dieselben drei Methoden, dieselbe Prüfung. Zwei unabhängige Analysen mit demselben Ergebnis sind so nah an einer Bestätigung, wie es ohne Adobe derzeit geht. Trotzdem gilt die Warnung aus den Repositories selbst: Das ist Härtung, kein Fix. Andere Pfade durch die Schwachstelle bleiben offen.
Die unbequeme Lehre für den DACH-Markt
Deutschland gehört zu den größten Magento-Märkten weltweit; Sansec schätzt die installierte Basis global auf rund eine Viertelmillion Shops. Ein erheblicher Teil davon läuft bei mittelständischen Händlern, deren „Sicherheitskonzept“ aus dem Hosting-Vertrag und halbjährlichen Updates besteht. StyleSmuggler straft genau dieses Modell. Gepatcht war das erste Opfer. Gescannt war es auch. Geholfen hat beides nichts.
Gleichzeitig zeigt der Vorfall, wie weit die Community den Hersteller abgehängt hat. Die Entdeckung, die Namensgebung, die Frühwarnung, die forensische Analyse, die ersten Patches und die Härtungsempfehlungen kamen von Sansec, einer niederländischen Hosting-Firma und einzelnen Entwicklern — innerhalb von 48 Stunden. Adobe lieferte in derselben Zeit: nichts. Kein Advisory, kein CVE, kein Workaround. Für eine Plattform, die sich an Enterprise-Kunden verkauft, ist das ein Armutszeugnis, über das in den Vertragsverhandlungen des nächsten Jahres noch geredet werden wird.
Die ehrliche Konsequenz für Shopbetreiber lautet nicht „Magento ist unsicher, wechselt das System“. Sie lautet: Sicherheit bei Magento ist ab sofort ein laufender Betriebszustand, kein Update-Rhythmus. Wer keinen Hoster oder keine Agentur hat, die an einem Freitagabend ein Home-Verzeichnis jenseits des Webroots prüfen kann, hat kein Sicherheitskonzept — er hat ein gutes Gewissen. Diese Woche zeigt, was das wert ist.