Adobe Commerces Zero-Day „StyleSmuggler“ traf Shops drei Tage vor dem Fix

Am 4. September 2026 um 22:20 UTC begannen Angreifer, Magento- und Adobe-Commerce-Shops mit einem unauthentifizierten Remote-Code-Execution-Exploit zu treffen, für den noch kein Hersteller-Patch existierte. Die Schwachstelle, geführt als CVE-2026-75650 und von der niederländischen Sicherheitsfirma Sansec „StyleSmuggler“ getauft, trägt einen CVSS-Wert von 10.0, das Maximum. Adobe veröffentlichte am 7. September das Notfall-Bulletin APSB26-146 und den Hotfix VULN-39341, drei Tage nach dem ersten bestätigten Eindringen. Als ein Fix existierte, hatten Angreifer bereits genug Zeit, dauerhafte Backdoors auf kompromittierten Shops zu installieren, und der Patch entfernt sie nicht.

Zum Weiterlesen: CISA stuft PolyShell als ausgenutzt ein, während die Magento-Kampagne Hunderte Shops trifft · Microsofts Patchday im Oktober 2026 stellt mit 1.407 Korrekturen einen Rekord auf.

Diese Lücke ist die Geschichte. In einer modernen E-Commerce-Plattform ist eine unauthentifizierte Code-Execution-Schwachstelle so schlimm, wie eine Schwachstelle nur sein kann: Die Angriffsfläche lautet schlicht „ist der Shop aus dem Internet erreichbar“, und die Beute umfasst Kundendaten, Zahlungsdaten, Admin-Zugangsdaten und die Möglichkeit, Payment-Skimmer in den Checkout einzuschleusen. StyleSmuggler erwies sich als ohne exotische Konfiguration ausnutzbar. Sansec reproduzierte die vollständige Kette auf sauberen Installationen von Magento Open Source 2.4.7, 2.4.8 und 2.4.9, und ein bestätigtes Opfer lief auf 2.4.6-p15 mit im Juli und August angewandten Patches und einem sauberen security:patch-status-Bericht, ein Beweis, dass die übliche Frage „Sind wir aktuell?“ nicht ausreichte.

Die zweistufige Kette

StyleSmuggler missbraucht das Template-System von Magento so, dass der Angriff in eine stille Stufe und eine auslösende Stufe zerfällt. Zuerst sendet ein nicht authentifizierter Angreifer eine GraphQL-Anfrage, deren styles-Eigenschaft eine injizierte PHP-Nutzlast trägt. Die Nutzlast läuft nicht sofort; sie wird auf der Festplatte in einer Datei abgelegt, die Magento im Normalbetrieb erzeugt, etwa einem Checkout-Fehlerbericht. Weil die Nutzlast als Styling-Daten getarnt ankommt, schlüpft sie an den Schutzmechanismen vorbei, die ausführbaren Code aus Templates heraushalten sollen, daher der Name.

Die zweite Stufe ist der clevere Teil. Magento rendert diesen vergifteten Inhalt später, während es eine seiner eigenen Standard-Transaktions-E-Mails zusammenbaut, die „Payment Transaction Failed Reminder“. Das bösartige PHP wird serverseitig während des Template-Renderings ausgeführt. Niemand muss die E-Mail öffnen, und der Angriff funktioniert auch dann, wenn die Nachricht nie zugestellt wird, ein Händler, der nie eine verdächtige Nachricht sieht, ist also nicht aus dem Schneider. Sansec merkt an, dass ein unerwarteter Schwall solcher Zahlungserinnerungen dennoch eine Untersuchung wert ist, auch wenn gewöhnliche abgelehnte Zahlungen dieselbe Benachrichtigung erzeugen.

Die Kette ist bedeutsam, weil sie nicht von einem falsch konfigurierten Theme oder einem nachlässigen Administrator abhängt. Sansec berichtete, dass die Wahl des Session-Speichers keinen Unterschied macht und dass ein Angreifer einmal an einem Shop mit Redis-gestützten Sessions scheiterte, acht Sekunden später aber erfolgreich war, indem er die Nutzlast über eine Datei einspeiste, die über Magento-Custom-Options hochgeladen wurde. Ein unveränderter Shop auf einem aktuellen Zweig lag im Zielbereich.

Ein Fix ohne Versionsnummer

Adobes Behebung ist ungewöhnlich, und das hat Folgen für alle, die nachweisen wollen, geschützt zu sein. Das Unternehmen lieferte keine neue Magento- oder Commerce-Version aus. Stattdessen verweist das Lösungsfeld von APSB26-146 auf die Zeichenfolge „Hotfix for CVE-2026-75650“, geliefert als Composer-Patch-Datei VULN-39341-composer-patches.zip, angewandt über Adobes Composer-Patch-Prozess. Wie das Sicherheitsportal Severity Daily anmerkte, verschiebt ein Composer-Patch den Versionsstring des Produkts nicht: Ein Shop mit angewandtem Hotfix und einer ohne melden dieselbe Adobe-Commerce-Version. Ein herkömmlicher, auf Versionsabgleich basierender Schwachstellen-Scanner kann sie nicht unterscheiden. Adobes empfohlene Überprüfung ist ein Shell-Befehl auf dem Host (in der Cloud vendor/bin/magento-patches -n status, gefiltert nach 39341), was Server für Server funktioniert, aber nicht zu einer flottenweiten Compliance-Prüfung skalierbar ist.

Die betroffene Bandbreite ist groß. Adobe listet Adobe Commerce 2.4.4 bis 2.4.9, einschließlich der August-2026-Releases und früherer Versionen in jedem Zweig; Adobe Commerce B2B 1.3.3 bis 1.5.3; und Magento Open Source 2.4.6 bis 2.4.9. Adobe sagt, der Hotfix sei nur gegen die August-2026-Releases dieser Zweige getestet worden und die Kompatibilität mit älteren Releases sei nicht bestätigt. Sansec berichtete separat von einer Reproduktion auf sauberen 2.4.7-, 2.4.8- und 2.4.9-Installationen.

Adobe machte außerdem klar, dass Patchen nicht die ganze Arbeit ist. Da die Schwachstelle einen Angreifer Code als Webserver ausführen lässt, ist potenziell alles erreichbar, was der Shop erreichen konnte, einschließlich des Verschlüsselungsschlüssels, der gespeicherte Geheimnisse schützt. Die Knowledge-Base-Anleitung weist Händler an, den Verschlüsselungsschlüssel und dann jedes von ihm geschützte Geheimnis zu rotieren: Admin-Passwörter, REST-, SOAP- und GraphQL-Integrationstoken, OAuth-Client-Secrets, API-Zugangsdaten der Zahlungs-Gateways, Datenbank-Zugangsdaten, SSH- und Deploy-Schlüssel sowie API-Schlüssel von Drittanbieter-Erweiterungen. Die alleinige Rotation des Schlüssels, so warnt die Seite, entwerte keine Zugangsdaten, die ein Angreifer bereits gelesen hat; sie müssten an der Quelle rotiert werden, etwa beim Zahlungs-Gateway.

Bevor der Hotfix erschien, war die Übergangsmilderung, GraphQL zu deaktivieren. Das ist ein unbequemer Kompromiss für moderne, API-getriebene und Headless-Storefronts, die GraphQL für ihr Frontend nutzen. Es war dennoch der direkteste Weg, die Injektionsstufe abzuschneiden, solange kein Fix existierte.

Eine Backdoor, die sich als Betriebssystem verkleidet

Was StyleSmuggler mehr als eine Patch-Geschichte macht, ist das, was die Angreifer zurücklassen. Sansecs forensische Analyse beschreibt ein kleines Rust-Programm, das als Hintergrundprozess läuft und sich mit einem Command-and-Control-Server verbindet. Frühe Proben kontaktierten 99.84.67.186; spätere Builds tarnen ihren Verkehr als Network Time Protocol und senden 48-Byte-UDP-Pakete an Port 123 (einen Port und ein Protokoll, die die meisten Egress-Filter durchwinken), wobei nur die ersten vier Bytes tatsächlich NTP ähneln. Der Rest trägt einen MessagePack-Datensatz mit Agent-ID, Hostname, Benutzername, Betriebssystemversion, Speicher- und Festplattenauslastung, Uptime, ob er als root läuft, und der Implantat-Version. Sansec erklärte, dass das Implantat mit seinem Update vom 11. September ntp.timesync.to und ntp.timesysnc.net auf 185.157.160.251 auflöste, die Adresse, die zu blockieren ist, wenn eine Filterung nach Namen nicht möglich ist.

Das Implantat versteckt sich, indem es die Namen gewöhnlicher Linux-Hausmeisterarbeit annimmt. Die erste Variante erschien als [kworker/u:8:0] und ahmte einen Kernel-Worker-Thread nach. Spätere Builds benannten sich in fc-cache um, kopierten nach ~/.cache/fontconfig/fc-cache, und dann in chronyd, den echten Namen des NTP-Daemons auf den meisten Distributionen. Die Persistenz kommt von Cron-Einträgen, die direkt in den Cron-Spool geschrieben statt über crontab -e hinzugefügt werden, sodass Systemprotokolle keine REPLACE-Zeile enthalten; beobachtete Zeitpläne liefen alle 30 Minuten. Sansec bemerkte zudem eine Variante, die ohne Cron-Eintrag mit Eltern-Prozess-ID 1 neu starten kann, eine leere Crontab ist also kein Beweis für einen sauberen Host.

Ein zweiter, unabhängiger Akteur wurde auf denselben Opfer-Shops beobachtet. Am 7. September analysierte Sansec einen 485 Byte großen PHP-Dropper, der eine Web-Shell in den Produktbild-Cache von Magento unter pub/media schreibt. Die Shell liefert einen 404 an jede Anfrage ohne den geheimen Header X-Cache-Token, und mit dem Header führt sie beliebiges PHP aus dem POST-Parameter task aus. Sansec fand den Dropper in einem Store:-Request-Header, noch JSON-escaped aus dem Datensatz, in den Magento ihn protokolliert hatte, ein Beleg, dass er über StyleSmuggler hereinkam. Die beiden Kampagnen teilen Opfer, aber nicht ihr Tooling. Tenables FAQ zur Schwachstelle meldete mehrere Opfer-Shops über verschiedene Kampagnen hinweg und dass die Incident-Response-Firma Disrex aus erster Hand Erfahrung mit mindestens zwei kompromittierten Shops hatte; eine öffentliche Zuordnung zu einer benannten Bedrohungsgruppe gab es bis zum 8. September nicht.

Das Patchen schließt das Loch, aber säubert keinen Shop, der bereits getroffen wurde. Die Shops wurden drei Tage lang ausgenutzt, bevor der Hotfix existierte.

Warum dieser Fall härter trifft

Adobe Commerce und Magento betreiben einen großen Teil der Online-Shops der Welt, und viele dieser Shops sind kleine oder mittelständische Unternehmen ohne eigenes Sicherheitsteam. Diese Kombination verstärkt jede Eigenschaft dieses Vorfalls. Der Exploit benötigte keine Anmeldung, die Exposition war also breit. Das Vor-Patch-Fenster erstreckte sich in manchen Regionen über ein Wochenende. Und die Nutzlasten waren darauf ausgelegt, die Behebung zu überleben. Ein Händler, der am ersten Tag patcht, beherbergt möglicherweise immer noch einen Angreifer, der am Tag null ankam.

Auch gibt es eine Compliance-Dimension. CISA nahm CVE-2026-75650 am 8. September in seinen Katalog bekannter ausgenutzter Schwachstellen auf und setzte eine Frist für Bundesbehörden auf den 11. September, ein Drei-Tage-Fenster, das weit enger ist als die Wochen, die CISA üblicherweise gewährt. Dieser Eintrag verpflichtet Bundesbehörden, Milderungen nach den neuen risikobasierten Patch-Regeln anzuwenden und eine forensische Triage durchzuführen, genau die Art von Pflicht, die schwierig wird, wenn die Behebung ein Patch ohne Versionsnummer und eine Checkliste zur Rotation von Zugangsdaten ist. Die praktische Lehre für privatwirtschaftliche Betreiber ist dieselbe: Die Frist mag sie nicht binden, die Dringlichkeit schon.

Der Vorfall bestärkt zudem ein Muster in der E-Commerce-Sicherheit. Die Template- und Rendering-Schichten sind immer wieder der Weg hinein, weil sie zwischen benutzergesteuertem Inhalt und serverseitiger Ausführung sitzen und weil die E-Mail-Pipeline leicht übersehen wird. Sansecs Empfehlung, nach frisch geschriebenen .php-Dateien unter pub/media zu suchen, ist bezeichnend (dieses Verzeichnis soll Bilder und Cache ausliefern, niemals Code), und Dateiintegritätsüberwachung eignet sich gut, um genau solche Anomalien zu erkennen.

Was zu beobachten ist

Vier Dinge werden bestimmen, wie dieser Vorfall in Erinnerung bleibt.

Erstens, ob Adobe den Hotfix in ein nummeriertes Release überführt. Composer-Patches sind eine vertretbare Notfallmaßnahme, doch die fehlende Versionsnummer macht jedes Asset-Inventar und jeden Scanner blind und lässt den Unterschied zwischen gepatcht und ungepatcht für die Werkzeuge unsichtbar, auf die die meisten Organisationen setzen.

Zweitens, ob das Implantat bewaffnet wird. Als Sansec seine Analyse veröffentlichte, gab es keinen Hinweis darauf, dass die Backdoor für mehr als Beaconing genutzt wurde, und die Malware wurde von keinem anderen Sicherheitsanbieter als Sansec erkannt. Das könnte sich schnell ändern.

Drittens, ob die Web-Shell des zweiten Akteurs die Speerspitze einer breiteren Magecart-Kampagne ist. Eine unauthentifizierte RCE, die den Checkout erreicht, ist ein natürlicher Ausgangspunkt für Kartendiebstahl-Code, und das Fenster zwischen erster Ausnutzung und Offenlegung gab Angreifern Zeit, sich zu positionieren.

Viertens, wie viele Shops tatsächlich kompromittiert wurden. Die bestätigten Opferzahlen sind noch klein und anekdotisch. Die wahre Zahl dürfte erst sichtbar werden, wenn Händler Kompromittierungsprüfungen durchführen und Prozesse namens kworker, fc-cache oder chronyd finden, die nicht dorthin gehören. Bis dahin ist die ehrliche Haltung für jeden, der zwischen dem 4. September und dem Moment des Patchings einen internetzugewandten Magento-Shop betrieben hat, eine Kompromittierung anzunehmen, bis das Gegenteil bewiesen ist, und Zugangsdaten erst nach Patch und Suche zu rotieren, in dieser Reihenfolge.