{"id":51323,"date":"2026-09-06T02:32:38","date_gmt":"2026-09-06T00:32:38","guid":{"rendered":"https:\/\/overcentral.com\/de\/?p=51323"},"modified":"2026-09-06T02:32:38","modified_gmt":"2026-09-06T00:32:38","slug":"style-smuggler-zero-day-magento-adobe-commerce-51323","status":"publish","type":"post","link":"https:\/\/overcentral.com\/de\/style-smuggler-zero-day-magento-adobe-commerce-51323\/","title":{"rendered":"Zero-Day-L\u00fccke in Magento und Adobe Commerce installiert Backdoor in Online-Shops"},"content":{"rendered":"

Eine kritische, noch ungepatchte Sicherheitsl\u00fccke in Magento Open Source und Adobe Commerce wird derzeit aktiv ausgenutzt, um Webshops mit einer persistenten Backdoor zu infizieren. Angreifer k\u00f6nnen ohne Authentifizierung beliebigen Code auf dem Server ausf\u00fchren \u2013 und das in allen aktuellen Versionen bis einschlie\u00dflich 2.4.9. Die niederl\u00e4ndische E-Commerce-Sicherheitsfirma Sansec<\/a> entdeckte die Schwachstelle, taufte sie StyleSmuggler<\/strong> und meldete die ersten Angriffe f\u00fcr den 4. September. Da Adobe bislang weder einen Patch noch einen Workaround bereitgestellt hat, m\u00fcssen Shopbetreiber sofort handeln.<\/p>\n

StyleSmuggler: Eine Zero-Day-L\u00fccke ohne Sicherheitsupdate<\/h2>\n

Sansec ver\u00f6ffentlichte die Informationen bewusst fr\u00fchzeitig, weil die Angriffe bereits in vollem Gange sind. Adobe selbst hat bis zum 6. September weder eine Sicherheitswarnung noch eine CVE-Nummer oder einen Patch ver\u00f6ffentlicht; der letzte Eintrag im Security Bulletin Index datiert vom 11. August. Ein erfolgreicher Angriff gew\u00e4hrt dem Angreifer Codeausf\u00fchrung auf dem Shop-Server und installiert eine dauerhafte Backdoor. Sansec konnte die vollst\u00e4ndige, nicht authentifizierte Angriffskette auf sauberen Magento-Open-Source-Installationen der Versionen 2.4.7, 2.4.8 und 2.4.9 reproduzieren. Das erste bekannte Opfer lief mit Version 2.4.6-p15, dem aktuellsten Patch-Level f\u00fcr diese Release-Linie, den Adobe selbst im August Bulletin als 2.4.6-2026-aug auflistet.<\/p>\n

Die Angriffskette: Von der Log-Datei zur Root-Shell<\/h2>\n

Der Exploit erfolgt in zwei Stufen. Zun\u00e4chst schleust der Angreifer PHP-Code in eine Datei ein, die Magento selbst anlegt \u2013 etwa beim Generieren eines Fehlerberichts in var\/report\/<\/code>codecodecode oder \u00fcber das Systemlog in var\/log\/system.log<\/code>codecodecode. Im zweiten Schritt wird Magento dazu gebracht, diese Datei auszuf\u00fchren, und zwar \u00fcber die Standard-E-Mail-Vorlage \u201ePayment Transaction Failed Reminder\u201c<\/strong>. W\u00e4hrend Magento die Nachricht rendert, wird der injizierte Code ausgef\u00fchrt \u2013 und das selbst dann, wenn die E-Mail-Zustellung fehlschl\u00e4gt.<\/p>\n

Die unabh\u00e4ngige Untersuchung durch die Magento-Hosting- und Entwicklungsfirma Disrex Group<\/a><\/strong> best\u00e4tigt diesen Ablauf. Disrex betreute zwei kompromittierte Shops und einen dritten, der angegriffen, aber nicht durchbrochen wurde. Die Lesart von Disrex besagt, dass eine Direktive im injizierten Text eine Kette von Magento-eigenen Klassen ansteuert, die schlie\u00dflich in Code m\u00fcndet, der f\u00fcr den Kommandozeilen-Dependency-Injection-Compiler existiert. Dieser inkludiert einen Dateipfad, den der Angreifer zuvor mit Schadcode bef\u00fcllt hat.<\/p>\n

Wichtig f\u00fcr die Forensik: Sansecs erster Suchindikator zielte auf die Datei var\/report\/<\/code>codecodecode mit dem Marker X_TRACE_<\/code>codecodecode. Disrex stellte jedoch fest, dass beide infizierten Shops \u00fcber var\/log\/system.log<\/code>codecodecode vergiftet wurden \u2013 ein reiner Report-Check h\u00e4tte die Infektion \u00fcbersehen. Der Marker driftet zudem: Disrex sah X-TRACE-<\/code>codecodecode mit zehn Hex-Zeichen am Morgen des 5. September<\/a>; am Nachmittag tauchte ein \u00e4hnlicher Header ohne das Wort TRACE auf. Ein TypeError von array_merge()<\/code>codecodecode mit einem Integer-Argument unmittelbar nach dem Include beweist den erfolgreichen Exploit \u2013 eine getarnte Variante hinterl\u00e4sst jedoch keinen Log-Eintrag.<\/p>\n

Die Backdoor: Getarnte Prozesse und persistente Cron-Jobs<\/h2>\n

Das finale Implantat tarnt sich als Linux-Kernel-Thread mit dem Namen [kworker\/u:8:0]<\/code>codecodecode, l\u00e4uft aber unter dem unprivilegierten Website-Benutzer. Die Bin\u00e4rdatei (ca. 1,9 MB, statisch gelinktes Rust-Programm f\u00fcr x86-64 und arm64) liegt unter ~\/.local\/share\/.gvfsd\/gvfsd-user<\/code>codecodecode \u2013 oberhalb des Document Root. Ein Cron-Eintrag startet die Backdoor alle f\u00fcnf Minuten neu, direkt in die Spool-Datei unter \/var\/spool\/cron\/crontabs\/<\/code>codecodecode geschrieben, sodass keine \u00c4nderung im Systemlog erscheint. Bei einem der Shops war die Zeile 1.728-mal vorhanden und wurde innerhalb einer Sekunde nach L\u00f6schung wiederhergestellt.<\/p>\n

Ein bemerkenswerter Fund: Auf einem der beiden kompromittierten Shops baute das Implantat keine einzige ausgehende Verbindung<\/strong> auf. Stattdessen hielt es 28 Verbindungen zur eigenen Redis-Instanz auf Port 6379 und las den Magento-Session-Speicher aus. Keines der beiden erstellten Paket-Captures (jeweils \u00fcber 200 MB) enthielt ein Paket an die von Sansec gelistete Download-Host- oder Command-and-Control-Adresse. Disrex best\u00e4tigte nach der Analyse, dass sich das Implantat auf den betroffenen Shop beschr\u00e4nkte, keine Lateralbewegung stattfand und kein weiterer Kunde auf der Platform infiziert wurde.<\/p>\n

Folgende Indikatoren (Indicators of Compromise \/ IOCs) wurden von Sansec und Disrex ver\u00f6ffentlicht:<\/p>\n

    \n
  • Prozess:<\/strong> [kworker\/u:8:0]<\/code>codecodecode unter einem Nicht-root-Benutzer<\/li>\n
  • Datei:<\/strong> ~\/.local\/share\/.gvfsd\/gvfsd-user<\/code>codecodecode<\/li>\n
  • Datei:<\/strong> ~\/.local\/share\/.gvfsd\/.gvfsd_<8hex>.lock<\/code>codecodecode<\/li>\n
  • Datei:<\/strong> \/tmp\/.gvfsd_<8hex>.lock<\/code>codecodecode<\/li>\n
  • Datei:<\/strong> \/tmp\/.kw_<\/code>codecodecode<\/li>\n
  • Cron:<\/strong> *\/5 * * * * exec <home>\/.local\/share\/.gvfsd\/gvfsd-user<\/code>codecodecode (alternative Variante mit \/tmp\/.kw_<\/code>codecodecode)<\/li>\n
  • SHA-256 (Sansec):<\/strong> e315687a1dfe61ef4a5a5642214db6d3b2b05d81391285eebc2af664641a26a7<\/code>codecodecode<\/li>\n
  • SHA-256 (Festplatte, Disrex):<\/strong> 8334b434fa3fe9f59cebe9609b11e0b1fd19d10212c45c705adec1902a1d06ef<\/code>codecodecode<\/li>\n
  • SHA-256 (im Speicher, Disrex):<\/strong> 251fabd50d7b18a8b5e1b3ef5d64e7198c17244778f6461fb1ab07f6169bf220<\/code>codecodecode<\/li>\n
  • Domain:<\/strong> 247.cdnflare[.]xyz<\/code>codecodecode (Malware-Download-Host)<\/li>\n
  • IPs:<\/strong> 99.84.67[.]186:443<\/code>codecodecode (C2 via WebSocket\/TLS), 88.216.72[.]181<\/code>codecodecode (Angreifer-Quelle), 5.181.86[.]133<\/code>codecodecode (Massenangriffe, Disrex)<\/li>\n<\/ul>\n

    Ein echter Kernel-Thread geh\u00f6rt root und hat keinen residenten Speicher; ein Name in eckigen Klammern unter dem Website-Benutzer mit realem Arbeitsspeicher ist das Implantat. Disrex empfiehlt, den Hash des laufenden Prozesses aus \/proc\/<PID>\/exe<\/code>codecodecode sowie der Datei auf der Festplatte zu ziehen, da die Bin\u00e4rdatei im Speicher eines Shops eine andere Build-Version aufwies als die Datei auf Disk. Pl\u00f6tzliche Ausbr\u00fcche von \u201ePayment Transaction Failed Reminder\u201c-E-Mails sind ein Warnsignal, auch wenn legitime abgelehnte Zahlungen dieselbe Benachrichtigung ausl\u00f6sen.<\/p>\n

    Sofortma\u00dfnahmen und Mitigationen bis zum offiziellen Patch<\/h2>\n

    Da Adobe noch keinen Patch geliefert hat, stehen vor\u00fcbergehende Optionen zur Verf\u00fcgung. Sansec r\u00e4t, GraphQL tempor\u00e4r zu deaktivieren<\/strong>, bis ein Fix erscheint. Headless- und PWA-Storefronts ben\u00f6tigen GraphQL allerdings \u2013 klassische und Hyv\u00e4-Storefronts kommen ohne aus. Der n\u00e4chste geplante Sicherheits-Release von Adobe ist f\u00fcr den 8. September angesetzt; ob dieser die L\u00fccke schlie\u00dft, ist nicht bekannt.<\/p>\n

    Disrex hat nginx- und Apache-Regeln ver\u00f6ffentlicht, die Anfragen mit den Exploit-Parametern in der URL-Querystring blockieren. Allerdings umgehen POST- und JSON-Bodies diese Regel, da die Webserver nur den Querystring pr\u00fcfen. Disrex betont, dass die Regeln lediglich die aktuelle Kampagne stoppen, nicht die Schwachstelle selbst.<\/p>\n

    Drei inoffizielle Patches stehen zur Verf\u00fcgung: Disrex bietet einen Composer-Patch<\/strong>, der eine Pr\u00fcfung in drei Dependency-Injection-Code-Scannern von Magento einf\u00fcgt, sodass diese nur in der Kommandozeile laufen. Allerdings bricht eine Drittanbieter-Erweiterung (mageplaza\/module-admin-permissions) auf, wenn ClassesScanner.php<\/code>codecodecode blockiert wird. Ein GitHub-Nutzer (ProxiBlue) ver\u00f6ffentlichte denselben Guard unabh\u00e4ngig am 5. September. Die Firma Graycore ver\u00f6ffentlichte ein Magento-Modul, das drei Punkte abdichtet: den E-Mail-Template-Block-Directive, den Grid-Row-URL-Generator und PHP-\u00d6ffnungs-Tags in Web-API-Fehlerberichten. Der bereitgestellte Code zum Zeitpunkt der Ver\u00f6ffentlichung enthielt jedoch nur eine fr\u00fchere H\u00e4rtung gegen einen PayPal-GraphQL-Resolver; Graycore selbst warnt, dass es sich um H\u00e4rtung, nicht um einen vollst\u00e4ndigen Fix handelt.<\/p>\n

    Unabh\u00e4ngig von der Angriffskette lassen sich zwei serverseitige Einstellungen empfehlen: Das Deaktivieren von proc_open<\/code>codecodecode in der disable_functions<\/code>codecodecode-Liste von PHP und das Mounten von \/tmp<\/code>codecodecode, \/var\/tmp<\/code>codecodecode und \/dev\/shm<\/code>codecodecode mit der Option noexec<\/code>codecodecode. In einem der von Disrex untersuchten F\u00e4lle waren vier der sechs vom Dropper probierten PHP-Funktionen deaktiviert, aber proc_open<\/code>codecodecode war aktiv, sodass der Dropper dar\u00fcber das Implantat starten konnte.<\/p>\n

    Wichtige Einschr\u00e4nkung des eComscan-Scanners<\/h3>\n

    Sansec empfiehlt seinen eigenen Scanner eComscan (Version 1.9.7) zur Erkennung. Disrex berichtet jedoch von einem Fehlalarm bei Store A: eComscan meldete den Shop als sauber, obwohl 1.728 Cron-Zeilen und die Backdoor aktiv waren. Ursache war der Scan-Pfad \u2013 der Scanner war nur auf das Document Root ausgerichtet, w\u00e4hrend das Implantat im Home-Verzeichnis eine Ebene dar\u00fcber lag. Disrex hat den Scan-Pfad inzwischen erweitert.<\/p>\n

    Was betroffene Shopbetreiber jetzt tun sollten<\/h2>\n

    Sollte eine Infektion festgestellt werden, empfiehlt Disrex eine klare Reihenfolge: Beweise sichern<\/strong>, dann den Cron-Eintrag entfernen, bevor der Prozess beendet wird (andernfalls stellt der Prozess den Cron selbst wieder her). Kein Reboot<\/strong>, da die Kopie unter \/proc<\/code>codecodecode m\u00f6glicherweise die einzige Bin\u00e4rdatei ist. Kein composer install<\/code>codecodecode zur Bereinigung, weil dabei die Timestamps \u00fcberschrieben werden, die Aufschluss \u00fcber die Manipulation geben. Nach der Entfernung sollten der Session-Speicher geleert, der crypt\/key<\/code>codecodecode in app\/etc\/env.php<\/code>codecodecode rotiert sowie alle Admin-Passw\u00f6rter, Zahlungsanbieter-API-Keys und Integrations-Credentials ausgetauscht werden.<\/p>\n

    Disrex betont ausdr\u00fccklich: Der Patch-Status des Shops war in beiden F\u00e4llen irrelevant<\/strong> \u2013 die verwundbare Stelle existiert unabh\u00e4ngig von Sicherheitsupdates, solange Adobe keine spezifische Korrektur liefert. Die Angreifer nutzen genau diese L\u00fccke, bevor ein Patch existiert. Hosting-Provider wie Nexcess und Liquid Web haben vorsorgliche Ma\u00dfnahmen angek\u00fcndigt, best\u00e4tigen aber noch keine eigenen Kompromittierungen.<\/p>\n

    Fazit: Keine Entwarnung in Sicht<\/h2>\n

    Die StyleSmuggler-L\u00fccke ist eine der schwerwiegendsten Bedrohungen f\u00fcr Magento- und Adobe-Commerce-Shops der letzten Jahre. Die vollst\u00e4ndige, nicht authentifizierte Codeausf\u00fchrung ohne Patch macht jedes System zum potenziellen Ziel. Der n\u00e4chste geplante Sicherheitsrelease von Adobe am 8. September k\u00f6nnte einen Fix enthalten \u2013 ob das der Fall sein wird, ist offen. Bis dahin m\u00fcssen Shopbetreiber auf die hier beschriebenen Mitigationen zur\u00fcckgreifen, ihre Systeme akribisch auf die genannten Indikatoren pr\u00fcfen und die Sicherheit ihrer gesamten Infrastruktur \u00fcberdenken. Die Angreifer haben bereits bewiesen, dass sie innerhalb weniger Stunden ganze Shops \u00fcbernehmen k\u00f6nnen \u2013 wer jetzt nicht handelt, riskiert nicht nur Datenverlust, sondern auch das Vertrauen seiner Kunden.<\/p>\n","protected":false},"excerpt":{"rendered":"

    Eine kritische, noch ungepatchte Sicherheitsl\u00fccke in Magento Open Source und Adobe Commerce wird derzeit aktiv ausgenutzt, um Webshops mit einer persistenten Backdoor zu infizieren. Angreifer k\u00f6nnen ohne Authentifizierung beliebigen Code auf dem Server ausf\u00fchren \u2013 und das in allen aktuellen Versionen bis einschlie\u00dflich 2.4.9. Die niederl\u00e4ndische E-Commerce-Sicherheitsfirma Sansec entdeckte die Schwachstelle, taufte sie StyleSmuggler und […]<\/p>\n","protected":false},"author":5,"featured_media":54042,"comment_status":"closed","ping_status":"","sticky":false,"template":"","format":"standard","meta":{"fifu_image_url":"https:\/\/cards.overcentral.com\/cards\/de\/51323.png","fifu_image_alt":"Zero-Day-L\u00fccke in Magento und Adobe Commerce installiert Backdoor in Online-Shops","footnotes":""},"categories":[6671],"tags":[],"class_list":["post-51323","post","type-post","status-publish","format-standard","has-post-thumbnail","category-scherheit"],"fifu_image_url":"https:\/\/cards.overcentral.com\/cards\/de\/51323.png","fifu_image_alt":"Zero-Day-L\u00fccke in Magento und Adobe Commerce installiert Backdoor in Online-Shops","_links":{"self":[{"href":"https:\/\/overcentral.com\/de\/wp-json\/wp\/v2\/posts\/51323","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/overcentral.com\/de\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/overcentral.com\/de\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/overcentral.com\/de\/wp-json\/wp\/v2\/users\/5"}],"replies":[{"embeddable":true,"href":"https:\/\/overcentral.com\/de\/wp-json\/wp\/v2\/comments?post=51323"}],"version-history":[{"count":2,"href":"https:\/\/overcentral.com\/de\/wp-json\/wp\/v2\/posts\/51323\/revisions"}],"predecessor-version":[{"id":51325,"href":"https:\/\/overcentral.com\/de\/wp-json\/wp\/v2\/posts\/51323\/revisions\/51325"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/overcentral.com\/de\/wp-json\/wp\/v2\/media\/54042"}],"wp:attachment":[{"href":"https:\/\/overcentral.com\/de\/wp-json\/wp\/v2\/media?parent=51323"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/overcentral.com\/de\/wp-json\/wp\/v2\/categories?post=51323"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/overcentral.com\/de\/wp-json\/wp\/v2\/tags?post=51323"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}