Drei Tage lang hatten Magento- und Adobe-Commerce-Betreiber keinen Schutz. Zwischen dem 4. und 7. September 2026 nutzten Angreifer eine bis dahin unbekannte Schwachstelle aus, um Online-Shops unauthentifiziert zu übernehmen und dauerhafte Backdoors zu installieren. Entdeckt hat die Kampagne das niederländische Sicherheitsunternehmen Sansec, das die Lücke „StyleSmuggler“ taufte. Adobe lieferte den Hotfix erst am Abend des 7. September – mit Prioritätsstufe 1, der höchsten Kategorie. Die Lücke trägt die Kennung CVE-2026-75650 und einen CVSS-Score von 10,0. Schlimmer geht es nicht.
Warum ist die Magento-Lücke CVE-2026-75650 so gefährlich?
Der Angriff benötigt weder Login noch Nutzerinteraktion: Ein einziger präparierter Request genügt, um auf dem Shop-Server eigenen Code auszuführen. StyleSmuggler schmuggelt PHP-Code über die styles-Eigenschaften von Magento-Templates ein und umgeht damit vorhandene Schutzmechanismen. Ausgelöst wird der Schadcode über eine Standardfunktion, die jeder Shop nutzt – die „Payment Transaction Failed“-E-Mail. Der Code läuft, sobald Magento die E-Mail rendert. Niemand muss sie öffnen.
Das Implantat selbst ist ein kompaktes Rust-Programm, das sich als Kernel-Prozess oder NTP-Daemon tarnt – Prozessnamen wie kworker, fc-cache oder zuletzt chronyd. Seine Kommunikation verkleidet es als NTP-Zeitsynchronisation auf UDP-Port 123. Wer ausgehenden Zeitsync-Traffic nicht genau prüft, sieht nichts. Sansec beobachtete zudem mindestens eine zweite, unabhängige Angreifergruppe, die über dieselbe Lücke eine Web-Shell in den Produktbild-Cache (pub/media) ablegte. Die Angreifer wechselten ihre Payloads seit dem 4. September mehrfach täglich.
Adobe-Hotfix VULN-39341: Versionen und Einspielung
Adobes Advisory APSB26-146 liefert den Fix nicht als reguläres Release, sondern als Composer-Patch. Getestet wurde er gegen die August-2026-Releases von Adobe Commerce und Magento Open Source 2.4.4 bis 2.4.9 sowie Commerce B2B 1.3.3 bis 1.5.3. Sansec konnte die komplette Angriffskette auf sauberen Installationen von 2.4.7, 2.4.8 und 2.4.9 reproduzieren – also auch auf dem aktuellsten Stand. Einen wichtigen Stolperstein nennt der Report gleich mit: Sessions in Redis oder der Datenbank stoppen den Angriff nicht, ein Upload über die Custom Options eines Produkts reichte als Ausweichroute.
Wer ältere Patch-Stände fährt, sollte sich auf die Meldung nicht verlassen, sondern prüfen: Am selben Tag wurde ein Shop auf 2.4.7-p10 angegriffen – Angriff und voller Patchstand zur selben Zeit. Nach der Installation des Hotfixes muss der Status explizit verifiziert werden, ein still fehlschlagender Composer-Patch ist kein Schutz.
Was Shop-Betreiber jetzt konkret tun müssen
Patch allein reicht nicht, denn er schließt das Loch, räumt aber keine bereits infizierte Instanz auf. Drei Tage wurde aktiv ausgenutzt, bevor es den Fix gab. Adobe empfiehlt, den Verschlüsselungsschlüssel zu rotieren – und danach jedes Credential, das dieser Schlüssel schützte: Admin-Passwörter, Integrations-Tokens für REST, SOAP und GraphQL, OAuth-Secrets, Zugangsdaten der Payment-Gateways, Datenbankzugänge, SSH- und Deploy-Keys sowie API-Keys von Drittanbieter-Extensions. Zwar umständlich, aber notwendig: Wer nur den Schlüssel tauscht, lässt alles Bestehen, was ein Angreifer bereits ausgelesen hat.
Zwei ungewöhnliche Signale helfen bei der Erstprüfung. Ein gehäuftes Auftreten von „Payment Transaction Failed“-E-Mails ohne erkennbaren Zahlungsgrund verdient einen Blick ins Server-Log. Und verdächtige PHP-Dateien unter pub/media gehören dort schlicht nicht hin – die Fundstelle der Web-Shell des zweiten Angreifers. Sicherheitswerkzeuge wie Sansecs eComscan erkennen das Implantat inzwischen; klassische Scanner erfassten es zum Veröffentlichungszeitpunkt noch nicht.
Für Magento-Nutzer war 2026 bereits kein ruhiges Jahr – nach SessionReaper und PolyShell ist StyleSmuggler die dritte kritische, unauthentifiziert ausnutzbare Lücke innerhalb von Monaten. Wer seinen Shop noch nicht gescannt und den Hotfix eingespielt hat, sollte beides nicht auf den nächsten Wartungsfenster-Termin schieben. Die Angreifer haben gezeigt, wie schnell sie iterieren: Vom ersten Exploit bis zur dritten Payload-Variante vergingen keine 72 Stunden.