Es gibt Sicherheitsmeldungen, bei denen der Satz „Spiel das Update ein“ genügt. Und dann gibt es diese hier. Die niederländische E-Commerce-Sicherheitsfirma Sansec hat am 5. September eine Lücke in Magento Open Source und Adobe Commerce öffentlich gemacht, für die es schlicht kein Update gibt. Der Name der Lücke: StyleSmuggler.
Sansec schreibt ungewöhnlich offen, warum die Veröffentlichung so früh kam: „Wir publizieren früh, weil gerade jetzt Shops kompromittiert werden.“ Die ersten Angriffe wurden am 4. September beobachtet — einen Tag vor der Warnung.
DER HAMMER: Auch der bestgepflegte Shop fiel um
Das eigentlich Erschreckende steckt im ersten Opferbericht. Der Shop lief auf Magento 2.4.6-p15 — dem höchsten Patch-Stand, den Adobe für diese Version überhaupt anbietet, inklusive der Sicherheitsupdates von Juli und August 2026. Er wurde trotzdem übernommen.
Sansec hat die komplette Angriffskette ohne jede Anmeldung auf frischen Installationen von 2.4.7, 2.4.8 und 2.4.9 nachgestellt. Der Hoster Disrex Group, der zwei betroffene Läden betreut hat, formuliert es noch deutlicher: „Der Patch-Stand war hier irrelevant — das ist der Teil, den Händler hören müssen.“
WIE ES FUNKTIONIERT: Magento richtet sich selbst hin
Der Angriff läuft in zwei Stufen und benutzt dabei ausschließlich Magentos eigene Bordmittel:
- Stufe eins: Der Angreifer schmuggelt PHP-Code in eine Datei, die Magento selbst schreibt — zum Beispiel in einen Fehlerbericht unter
var/report/oder invar/log/system.log. - Stufe zwei: Er löst die ganz normale Magento-Mail „Payment Transaction Failed Reminder“ aus. Beim Zusammenbauen dieser Nachricht führt Magento die vergiftete Datei aus. Niemand muss die Mail öffnen — es reicht, dass Magento sie rendert. Selbst wenn der Mailversand fehlschlägt, ist der Angriff erfolgreich.
DIE HINTERTÜR: Ein falscher Kernel-Prozess
Was danach auf dem Server liegt, ist bewusst unauffällig gebaut. Das Implantat tarnt sich als Prozess mit dem Namen [kworker/u:8:0] — das sieht aus wie ein echter Linux-Kernel-Thread. Der Unterschied: Ein echter Kernel-Thread gehört root und belegt keinen Arbeitsspeicher. Läuft der Prozess unter deinem Seiten-Benutzer und frisst RAM, ist es der Schädling.
Die Binärdatei liegt unter ~/.local/share/.gvfsd/gvfsd-user — also oberhalb des Web-Verzeichnisses. Genau daran scheiterte bei einem der Shops sogar ein Malware-Scan: Er war auf das Document-Root angesetzt, der Schädling saß eine Ebene höher. Ein Cron-Eintrag startet den Prozess alle fünf Minuten neu. Auf einem Shop stand diese Zeile 1.728 Mal in der Crontab, und sie war binnen einer Sekunde nach dem Löschen wieder da.
DAS FRÜHWARNSIGNAL, das keine Software braucht
Einer der beiden Vorfälle wurde durch eine E-Mail aufgedeckt — und zwar durch eine kaputte. Der Shop schickte seinem eigenen Betreiber eine Zahlungsfehler-Benachrichtigung, in der die Platzhalter nie ersetzt wurden: roher {{var ...}}-Text im Fließtext, eine Kundenadresse auf einer .invalid-Domain, Gesamtsumme null.
Das ist kein defekter Auftrag, sondern der Abgas-Ausstoß des Angriffs, der durch Magentos Template-Filter läuft. Der Händler leitete die Mail weiter — und binnen einer Stunde war das Implantat gefunden. Ungewöhnliche Häufungen solcher Mails sind das nützlichste Frühwarnzeichen, weil du dafür kein Werkzeug brauchst.
WAS DU JETZT TUN KANNST
Einen offiziellen Fix gibt es nicht. Adobes nächster planmäßiger Sicherheitstermin ist der 8. September — ob die Lücke darin vorkommt, ist offen. Bis dahin bleiben Behelfslösungen:
- GraphQL vorübergehend abschalten. Sansecs Empfehlung. Wichtig: Headless- und PWA-Storefronts brauchen GraphQL, klassische und Hyvä-Storefronts meist nicht.
proc_openindisable_functionseintragen. Bei einem der Opfer waren vier der sechs PHP-Funktionen gesperrt, die der Schadcode ausprobierte —proc_opennicht, und genau darüber startete das Implantat./tmp,/var/tmpund/dev/shmmitnoexecmounten, damit eine heruntergeladene Binärdatei gar nicht erst starten kann.- Beide Verzeichnisse durchsuchen —
var/report/undvar/log/system.log. Sansecs Prüfroutine schaut nur in das erste, beide Disrex-Infektionen liefen über das zweite.
Und falls du schon betroffen bist: erst Spuren sichern, dann den Cron-Eintrag entfernen bevor du den Prozess killst (sonst schreibt er ihn zurück), nicht neu starten, und auf keinen Fall mit composer install aufräumen — das überschreibt genau die Zeitstempel, die zeigen, was angefasst wurde.
Übrigens: Betreibst du keinen Shop, sondern WordPress oder ein anderes CMS? Die Lehre bleibt dieselbe. Ein Programm, das seine eigenen Log-Dateien wieder einliest, ist eine Angriffsfläche — unabhängig vom Hersteller.