Magento Zero-Day CVSS 10.0: Backdoor in Onlineshops

Ein Magento Zero-Day mit dem CVSS-Höchstwert 10.0 wird seit dem 4. September aktiv ausgenutzt. Angreifer führen ohne Anmeldung Code auf dem Shopserver aus und installieren eine dauerhafte Backdoor. Betroffen sind alle Versionen von Magento Open Source und Adobe Commerce von 2.4.4 bis einschließlich 2.4.9. Adobe hat den Hotfix erst am 7. September ausgeliefert, rund 70 Stunden nach dem ersten bestätigten Angriff. Der erste dokumentierte Opfershop war zum Zeitpunkt der Übernahme vollständig gepatcht.

Zwei Stufen, kein Login: So läuft der Angriff

Das Forensik-Team der niederländischen Sicherheitsfirma Sansec hat die Lücke am 4. September um 22:40 UTC entdeckt und auf den Namen StyleSmuggler getauft. Der Angriff schleust Schadcode in das Template-System von Magento ein. Über die styles-Eigenschaften, also Parameter, die Magento beim Rendern von Layout-Daten verarbeitet, umgeht er die vorhandenen Schutzmechanismen.

Die Ausführung läuft in zwei Stufen. Zuerst platziert der Angreifer PHP-Code, etwa indem er einen Fehlerreport erzeugen lässt. Danach bringt er Magento dazu, die Standard-Mail „Payment Transaction Failed Reminder“ zu rendern. Genau dabei wird der präparierte Code ausgeführt. Niemand muss die Mail öffnen oder empfangen, und der Angriff gelingt auch dann, wenn der Mailversand fehlschlägt.

In den Zugriffslogs tauchen unter anderem diese Muster auf:

POST /graphql?styles[....]=
POST /paypal/transparent/response/?<?=eval(base64_decode('....
GET /customer/section/load/?sections=customer&force_new_section_timestamp=true

2.4.6-p15 mit allen Patches – und trotzdem übernommen

Sansec hat die vollständige, unauthentifizierte Angriffskette auf sauberen Installationen von Magento Open Source 2.4.7, 2.4.8 und 2.4.9 nachgestellt. Das erste bekannte Opfer betrieb 2.4.6-p15 mit den Sicherheitspatches von Juli und August 2026. Der Befehl security:patch-status meldete den Shop als sauber. Am 7. September wurde zusätzlich ein Angriffsversuch gegen einen Shop mit 2.4.7-p10 registriert. Der Patchstand vor dem Hotfix war damit kein Schutz.

Auch die Verlagerung der Sessions nach Redis oder in die Datenbank stoppt den Angriff nicht. Ein Händler meldete einen Versuch, der an der Session-Speicherung scheiterte. Acht Sekunden später gelang dem selben Akteur ein zweiter Versuch über eine Datei, die er zuvor über die Custom Options von Magento hochgeladen hatte.

Hotfix VULN-39341: Patchen, scannen, Schlüssel tauschen

Adobe hat das Advisory APSB26-146 am 7. September um 20:20 UTC veröffentlicht, mit der höchsten Prioritätsstufe 1. Die Lücke trägt seitdem die Kennung CVE-2026-75650 und den CVSS-Wert 10.0. Der Fix kommt als Hotfix, nicht als vollständiges Release. Du lädst VULN-39341-composer-patches.zip von repo.magento.com und spielst die Datei als Composer-Patch ein.

vendor/bin/magento-patches -n status | grep "39341\|Status"

Adobe hat den Hotfix gegen die 2026-aug-Releases von Adobe Commerce 2.4.4 bis 2.4.9, Magento Open Source 2.4.4 bis 2.4.9 und Adobe Commerce B2B 1.3.3 bis 1.5.3 getestet. Ältere Stände in diesen Zweigen sind ebenfalls verwundbar, dort ist der Patch aber ungeprüft.

Adobe empfiehlt zusätzlich, den Encryption Key und jede damit geschützte Zugangsdatei zu tauschen: Admin-Passwörter, Integrationstokens für REST, SOAP und GraphQL, OAuth-Client-Secrets, API-Zugangsdaten der Zahlungsdienstleister, Datenbank-Zugangsdaten, SSH- und Deploy-Keys sowie API-Keys von Drittanbieter-Erweiterungen. Der Tausch muss an der Quelle erfolgen, nicht nur innerhalb von Magento. Ein neuer Encryption Key macht nichts ungültig, was ein Angreifer bereits ausgelesen hat.

Patchen allein reicht nicht. Der Hotfix schließt die Lücke, säubert aber keinen bereits kompromittierten Shop. Drei Tage lang wurden Shops angegriffen, bevor es überhaupt einen Fix gab.

Die Backdoor meldet sich als NTP-Server – im 60-Sekunden-Takt

Bei erfolgreichem Angriff startet ein getarnter Hintergrundprozess. Dahinter steckt ein kleines Rust-Programm, das eine Verbindung zum Command-and-Control-Server 99.84.67.186 aufbaut und auf Befehle wartet. Sansec hat bislang keinen Hinweis darauf, dass die Backdoor bereits genutzt wurde. Zum Zeitpunkt der Veröffentlichung erkannte kein anderer Sicherheitsanbieter den Implant.

Der Prozess läuft unter drei bekannten Namen: [kworker/u:8:0], fc-cache und chronyd. Die fc-cache-Builds vom 6. September für arm64 und x86-64 kopieren sich nach ~/.cache/fontconfig/fc-cache, legen einen Cron-Eintrag mit 13,43 * * * * an und schreiben ihre Prozess-ID nach /tmp/.fc_<8hex>.lock.

Die Kommunikation ist als Zeitsynchronisation getarnt. Alle 60 Sekunden löst der Implant ntp.timesync.to auf und schickt 48 Byte große UDP-Pakete an Port 123, die wie Antworten eines NTP-Servers aussehen. Nur die ersten vier Byte sind echtes NTP. Der Rest transportiert einen MessagePack-Datensatz mit Agent-ID, Hostname, Benutzername, Betriebssystemversion, Speicher- und Plattenauslastung, Laufzeit, Root-Status und Implant-Version, im Build vom 6. September 2.1.4. Als Ausweichadressen dienen ntp.synctime.to und ntp.syncstime.to. Am 7. September zeigten ntp.timesync.to und ntp.timesysnc.net auf 185.157.160.251.

Vor dem ersten Beacon ermittelt der Implant die öffentliche IP des Shops über unverschlüsseltes HTTP bei api4.ipify.org, ipv4.icanhazip.com, ipv4.ident.me und ipinfo.io. Der dabei genutzte User-Agent bricht nach AppleWebKit/537.36 ab und passt damit zu keinem echten Browser.

Am 7. September benannte sich der Implant auf einem bereits infizierten Host in chronyd um, den Namen des echten NTP-Dienstes vieler Linux-Distributionen, und meldete Version 2.1.5. Die Agent-ID blieb identisch, es handelt sich also um dieselbe Infektion. Die Persistenz variiert: In einem Fall entstand ein Cron-Eintrag mit 57,27 * * * *, direkt in die Cron-Spool-Datei geschrieben, sodass im Syslog keine REPLACE-Zeile auftaucht. In einem anderen Fall gab es gar keinen Cron-Eintrag. Eine leere Crontab ist damit kein Beleg für ein sauberes System.

Zwei Merkmale unterscheiden den Implant von einem echten NTP-Client: Er sendet alle 60 Sekunden neun Datagramme im Abstand von rund 10 Millisekunden statt eines einzigen, und jedes Datagramm ist als NTPv4 Server Mode markiert, was ein Client nie tut. Zusätzlich liest der Implant TracerPid aus /proc/self/status. Wird er beobachtet, installiert er sich zwar, sendet aber keine Beacons.

Diese Kommandos prüfen deinen Server auf die bekannten Spuren:

crontab -l | grep -i gvfsd
ls -la ~/.local/share/.gvfsd/ ~/.cache/fontconfig/fc-cache /tmp/.kw_* /tmp/.cache_* /tmp/.gvfsd-* /tmp/.fc-*/fc-cache /tmp/fc-cache /tmp/.chrony-*/chronyd 2>/dev/null
ps -eo pid,comm,args | grep -iE 'kworker|fc-cache|chronyd'
grep -r 'crontab command not allowed' /var/log/
grep -ril 'x_trace_' var/report/

Ein weiteres Signal sind ungewöhnlich viele „Payment Transaction Failed Reminder“-Mails. Legitime abgelehnte Zahlungen erzeugen dieselbe Benachrichtigung, ein plötzlicher Anstieg ist trotzdem ein Prüfgrund.

Ein zweiter Angreifer legt Webshells in pub/media ab

Nicht jede Schadsoftware auf den betroffenen Shops stammt von derselben Gruppe. Am 7. September analysierte Sansec einen 485 Byte großen PHP-Dropper eines anderen Akteurs, der ebenfalls über StyleSmuggler eindringt. Er schreibt eine Webshell in den Produktbild-Cache, nach dem Muster pub/media/catalog/product/cache/ss_<10hex>/sync_<10hex>.php. Ohne den Header X-Cache-Token antwortet die Shell mit 404. Mit dem Header führt sie beliebigen PHP-Code aus dem POST-Parameter task aus.

Davor läuft eine Aufklärungsanfrage: ein POST auf /graphql mit einer harmlosen Abfrage als Tarnung, während der eigentliche Code im Request-Header Store: steckt. Er liest Kernel- und Betriebssystemkennung, den PHP-Benutzer, das Arbeitsverzeichnis und die Schreibrechte auf pub/media aus. Das Ergebnis wird auf die Zeichen a bis z, 0 bis 9 und Bindestrich reduziert, in 50 Zeichen lange Blöcke zerlegt und als DNS-Hostname an eine oast.site-Subdomain gesendet. Der Angreifer setzt die Antwort aus dem Callback-Log zusammen und braucht nie eine HTTP-Antwort.

Das Beenden des Hintergrundprozesses reicht deshalb nicht aus. Verdächtige PHP-Dateien im Medienverzeichnis findest du so:

find pub/media -name '*.php'

Chronologie: 70 Stunden zwischen Angriff und Hotfix

Sansec kündigt eine vollständige Analyse von Gadget-Chain, Dropper und Implant an und aktualisiert die Indikatoren laufend. Der jüngste Stand datiert auf den 7. September, 20:45 UTC.