1.728 Cron-Einträge in einer einzigen Datei. So oft hatte sich die Hintertür auf einem kompromittierten Magento-Shop selbst neu installiert — innerhalb weniger Stunden, einmal pro Löschversuch, binnen einer Sekunde. Die Zahlen stammen aus dem Incident-Report der Disrex Group, die Anfang September zwei geknackte Shops bereinigte, während es für die ausgenutzte Lücke noch nicht einmal einen Namen gab. Inzwischen hat sie einen: StyleSmuggler, CVE-2026-75650, CVSS-Score 10,0. Die höchstmögliche Bewertung, vergeben für eine Schwachstelle in Magento Open Source, Adobe Commerce und Adobe Commerce B2B, die ohne Login aus dem Netz heraus Code auf dem Server ausführt.
Dreharbeiten für diesen Angriff begannen am 4. September 2026. Das niederländische Sicherheitsunternehmen Sansec, Spezialist für E-Commerce-Forensik, entdeckte die Lücke, weil live angegriffene Shops auf seinen Systemen auftauchten — und veröffentlichte am 5. September eine Warnung, bevor Adobe überhaupt ein Advisory hatte. Erst am 7. September um 20:20 Uhr UTC lieferte Adobe mit dem Bulletin APSB26-146 einen Hotfix nach. Drei Tage lang war jeder Magento-Shop auf diesem Planeten ohne Herstellerschutz angreifbar.
Was macht StyleSmuggler so gefährlich?
Die kurze Antwort: Der Angriff braucht weder Zugangsdaten noch Nutzerinteraktion, funktioniert gegen vollständig gepatchte Systeme und endet in einer persistenten Hintertür. Sansec reproduzierte die komplette unauthentifizierte Angriffskette auf sauberen Installationen der Versionen 2.4.7, 2.4.8 und 2.4.9. Das erste bekannte Opfer lief auf 2.4.6-p15 — dem höchsten Patchlevel, das Adobe für diesen Release-Zweig überhaupt anbietet, inklusive der Sicherheitsupdates vom Juli und August 2026.
Die Eleganz der Attacke liegt in ihrer Banalität. Angreifer schleusen PHP-Code in eine Datei ein, die Magento selbst schreibt — etwa ein Fehlerprotokoll unter var/log/system.log. Anschließend lösen sie über die Shop-Funktion „Payment Transaction Failed Reminder“ eine E-Mail aus. Beim Rendern des E-Mail-Templates führt Magento die präparierte Datei aus. Niemand muss diese Mail öffnen. Sie muss nicht einmal zugestellt werden.
Das hat einen unangenehmen Nebeneffekt: Auslöser des Angriffs ist eine Standard-Benachrichtigung über eine fehlgeschlagene Zahlung. Jeder Shop mit normalem Transaktionsaufkommen erzeugt solche Mails legitimerweise. Die Angriffsanfragen verstecken sich damit im Rauschen des Alltagsgeschäfts.
Wie arbeitet die Hintertür im System?
Was die Angreifer installieren, ist kein hastig zusammengeschriebenes Skript, sondern ein statisch gelinktes Rust-Binary von rund 1,9 Megabyte, kompiliert für x86-64 und arm64. Es tarnt sich als Linux-Kernel-Thread mit dem Prozessnamen [kworker/u:8:0] und liegt nicht im Webroot, sondern im Home-Verzeichnis des Shop-Nutzers unter ~/.local/share/.gvfsd/gvfsd-user. Ein Cronjob startet den Prozess alle fünf Minuten neu — direkt in die Spool-Datei geschrieben, sodass das Systemlog keinen Hinweis auf die Manipulation gibt.
Besonders aufschlussreich ist das Verhalten des Implantats auf einem der beiden Disrex-Fälle: Es baute keinerlei ausgehende Verbindung zum Command-and-Control-Server auf. Stattdessen hielt es 28 Verbindungen zur eigenen Redis-Instanz des Shops offen und las dort den Magento-Session-Speicher aus. Wer Session-Daten liest, kommt an Warenkörbe, Kundenkonten und im ungünstigsten Fall an Zahlungsdaten — ganz ohne auffälligen Netzwerkverkehr, den eine Firewall bemerken würde.
Patch status was irrelevant here, which is the part merchants most need to hear.
Dieser Satz der Disrex Group gegenüber The Hacker News fasst die Lektion zusammen: Beide kompromittierten Shops fielen in einem Zeitfenster von rund acht Stunden — zwischen dem ersten beobachteten Angriff und dem Moment, in dem überhaupt irgendeine Verteidigung existierte. Ein Shop war Sansec-Shield-Kunde mit aktivem Schutzmodul. Es half nichts, weil die Blockierregeln für diese Lücke noch nicht geschrieben waren.
Warum half Patchen diesmal nicht?
Weil Zero-Days per Definition schneller sind als jeder Patch-Zyklus — und weil die E-Commerce-Branche sich an ein Sicherheitsmodell gewöhnt hat, das auf Reaktion statt auf Härtung setzt. Adobe veröffentlicht Security-Patches im Zwei-Monats-Rhythmus; das letzte reguläre Bulletin stammte vom 11. August. Zwischen zwei Release-Terminen liegt genug Zeit für eine professionell organisierte Kampagne. Disrex zählte auf nur zwei Shops 26 verschiedene Angreifer-IP-Adressen, großteils aus einem Residential-Proxy-Pool. Wer wie in Sansecs Advisory eine einzelne Angreifer-Adresse blockte, stoppte weniger als ein Viertel des beobachteten Traffics.
Es gibt aber einen ehrlichen Teil der Geschichte, der den Ermittlern gehört. Einen der beiden Disrex-Fälle entdeckte nicht ein Scanner, sondern der Shop-Betreiber selbst: Er erhielt eine fehlerhafte „Payment Transaction Failed“-Mail — voller unaufgelöster Template-Variablen, mit einer Kundenadresse auf einer .invalid-Domain und einem Bestellwert von null. Er leitete die Mail weiter. Innerhalb einer Stunde war das Implantat gefunden. Der wertvollste Frühwarnsensor in dieser Geschichte war ein Mensch, der eine komische E-Mail nicht wegklickte.
Was müssen Händler und Agenturen jetzt prüfen?
Die direkte Antwort: erst den Hotfix, dann die Forensik, dann die Härtung — in genau dieser Reihenfolge, aber ohne die letzten beiden Punkte zu streichen. Adobes Hotfix VULN-39341 aus Bulletin APSB26-146 wird als Composer-Patch eingespielt; Disrex stellt zusätzlich ein Composer-Plugin bereit, das die installierte Version erkennt und den offiziellen Fix automatisch anwendet. Wer GraphQL nicht für Headless- oder PWA-Frontends benötigt, sollte es bis zur Patch-Installation deaktivieren — die Interimsempfehlung, die Sansec in den kritischen Tagen gab.
Patch allein reicht nicht, denn die Lücke wurde seit dem 4. September ausgenutzt. Konkret bedeutet das:
- Die Verzeichnisse
var/log/undvar/report/nach verdächtigen Markern durchsuchen — nicht nur nach dem String „X_TRACE_“, denn die Angreifer änderten die Signatur noch am selben Tag. - Nach einem Prozess
[kworker/u:8:0]suchen, der einem normalen Nutzer gehört und realen Speicher belegt — echte Kernel-Threads laufen als root und ohne Resident Memory. - Cron-Tabellen, Home-Verzeichnisse und
/tmpauf die bekannten Dateipfade und Hashes prüfen; Sansecs eComscan und vergleichbare Scanner nur mit erweitertem Scanpfad einsetzen, da das Implantat oberhalb des Document Root liegt. - Bei Befund: Session-Speicher leeren, den
crypt/keyinapp/etc/env.phprotieren und sämtliche Admin-Passwörter sowie API-Schlüssel der Zahlungsanbieter austauschen — das Implantat las den Session-Speicher mit.
Warum trifft das den deutschen Mittelstand besonders?
Magento Open Source und Adobe Commerce sind im DACH-Mittelstand unverhältnismäßig stark vertreten — vom Ersatzteilhändler mit B2B-Portal bis zum traditionsreichen Versandhaus, dessen Shop eine Agentur in München oder Leipzig betreut. Genau diese Betreiber patchen oft im Wochenrhythmus, nicht im Stundentakt. Und genau hier beginnt die juristische Dimension: Wer Kunden-Sessions und möglicherweise Zahlungsdaten verliert, hat eine meldepflichtige Datenschutzverletzung nach Artikel 33 DSGVO. Die 72-Stunden-Frist zur Meldung an die Aufsichtsbehörde läuft ab dem Moment, in dem der Verstoß bekannt wird — nicht ab dem Patch-Termin.
Zwei Server-Härtungen, die unabhängig von dieser konkreten Lücke funktionieren, empfiehlt Disrex ausdrücklich: proc_open in PHPs disable_functions aufnehmen und /tmp, /var/tmp sowie /dev/shm mit noexec mounten. Beides hätte die Installation des Rust-Implantats erschwert — auf einem der beiden Opfershops war proc_open die einzige nicht deaktivierte Funktion, und genau sie nutzte der Dropper.
Der bequeme Teil der Deutung wäre: Adobe hat gepatcht, Fall erledigt. Die unbequeme Wahrheit lautet anders. Eine Plattform, auf der Millionen Shops laufen und deren E-Mail-Template-Engine sich zur Code-Ausführung missbrauchen lässt, wird wieder angegriffen werden — die nächste Lücke ist eine Frage der Zeit, nicht der Wahrscheinlichkeit. Händler, die aus StyleSmuggler nur die Lektion „schneller patchen“ mitnehmen, haben die eigentliche verpasst: Sicherheit im Shop-System ist kein Update-Abo, sondern eine Betriebsdisziplin — mit harten Server-Defaults, überwachten Logs und jemandem, der die komische E-Mail am Freitagabend ernst nimmt.
Fertig. Kurz zur Einordnung der Quellenlage:
– Kernfakten stammen aus [The Hacker News (05./08.09.2026)](https://thehackernews.com/2026/09/unpatched-magento-and-adobe-commerce.html) und dem [Sansec-Advisory](https://sansec.io/research/stylesmuggler) — CVE-2026-75650, CVSS 10,0, aktive Ausnutzung seit 04.09., Adobe-Hotfix APSB26-146 seit 07.09.
– Der Artikel trägt die Patchesituation korrekt: Hotfix existiert seit 7. September, Forensik- und Härtungsteil bleibt trotzdem aktuell.
– DACH-Kontext (DSGVO Art. 33, Mittelstand-Relevanz) wurde ergänzt, ohne externe Links im HTML.