CVE-2026-75650: Adobe fixt aktiv ausgenutzte Magento Zero-Day, um Backdoors zu installieren

Adobe hat ein dringendes Sicherheitsupdate veröffentlicht, das eine Schwachstelle mit höchster Schwere in Adobe Commerce und Magento Open Source adressiert, die Angreifer bereits aktiv ausnutzen. Unter CVE-2026-75650 verfolgt und mit 10,0 auf der CVSS-Skala bewertet, ermöglicht die Schwachstelle eine nicht authentifizierte Remote-Code-Ausführung auf anfälligen E-Commerce-Servern.

Die Schwachstelle, genannt StyleSmuggler vom E-Commerce-Sicherheitsunternehmen Sansec, missbraucht die Vorlagenverarbeitungsfunktionalität von Magento, um bösartigen PHP-Code einzuschleusen und auszuführen. Angriffe wurden erstmals am 4. September 2026 bestätigt, mehrere Tage bevor Adobe seinen dringenden Hotfix am 7. September veröffentlicht hat.

Bedrohungsakteure haben den Zero-Day bereits genutzt, um ein Rust-basiertes Linux-Backdoor und in separaten Angriffen eine PHP-Web-Shell zu implementieren, die in der Lage ist, beliebige PHP-Befehle auszuführen. Da die Ausnutzung weder ein gültiges Magento-Konto noch eine Benutzerinteraktion erfordert, sollten internetfähige Shops, die gefährdete Builds betreiben, als hochpriorisierte Ziele für Patch- und rückblickende Untersuchungen angesehen werden.

CVE-2026-75650-Analyse

Adobe klassifiziert die Schwachstelle als CWE-1336: Unsachgemäße Neutralisierung spezieller Elemente in einer Template-Engine. Der CVSS-Vektor zeigt netzwerkbasierte Ausnutzung, geringe Komplexität des Angriffs, keine Privilegien und keine Benutzerinteraktion, mit potenziell hohem Einfluss auf Vertraulichkeit, Integrität und Verfügbarkeit.

Die wichtigsten Details zu CVE-2026-75650 betreffen die Art und Weise, wie Magento von Angreifern kontrollierte Daten während der normalen Anwendungsbearbeitung in ausführbares PHP umwandelt. StyleSmuggler missbraucht Template-Direktiven und interne Abhängigkeitsinjektionsfunktionen, anstatt sich auf eine bösartige Erweiterung oder Administratorenkonto zu verlassen.

Auf hoher Ebene folgt der bekannte Angriff zwei Phasen. Zuerst wird PHP-Inhalt, der von Angreifern kontrolliert wird, in eine Datei geschrieben, auf die Magento später zugreifen kann, wie z.B. ein Anwendungsprotokoll oder Bericht. Eine zweite Anfrage führt dann dazu, dass Magentos Vorlagenverarbeitungskette die Abhängigkeitsinjektions-Scannerfunktionalität erreicht, die die vergiftete Datei mit PHP include oder require_once lädt. Da diese Funktionen PHP interpretieren anstatt die Datei nur zu lesen, wird der von Angreifern kontrollierte Code auf dem Server ausgeführt.

Sansec beschreibt einen weiteren beobachtbaren Aspekt der Kette: Angreifer lösen gezielt Magentos normale Erinnerung an fehlgeschlagene Zahlungstransaktionen -E-Mail aus. Der bösartige Code läuft während Magento das Template rendert, sodass ein Kunde oder Administrator die E-Mail nicht öffnen muss. Der Exploit kann sogar erfolgreich sein, wenn die eigentliche E-Mail-Zustellung fehlschlägt.

Kontakt Vertrieb

CVE-2026-75650 betrifft laut Adobes Notfallhinweis folgende Adobe Commerce-Versionen:

• 2.4.9-2026-aug und früher
• 2.4.8-2026-aug und früher
• 2.4.7-2026-aug und früher
• 2.4.6-2026-aug und früher
• 2.4.5-2026-aug und früher
• 2.4.4-2026-aug und früher

Betroffene Adobe Commerce B2B-Versionen sind:

• 1.5.3-2026-aug und früher
• 1.5.2-2026-aug und früher
• 1.4.2-2026-aug und früher
• 1.3.4-2026-aug und früher
• 1.3.3-2026-aug und früher

Magento Open Source-Versionen bis 2.4.9-2026-aug sind ebenfalls durch Adobes Bulletin abgedeckt.

Sansec reproduzierte die vollständige nicht authentifizierte Angriffskette unabhängig auf sauberen Magento Open Source 2.4.7, 2.4.8 und 2.4.9 Installationen. Der erste bestätigte kompromittierte Kunde betrieb Magento 2.4.6-p15 mit den Sicherheitsupdates vom Juli und August, was zeigt, dass Systeme, die vor dem 7. September als vollständig gepatcht galten, immer noch anfällig für den Zero-Day waren.

Sobald die Remote-Code-Ausführung erreicht ist, erstreckt sich die Kompromittierung über Magento selbst hinaus. Die erste beobachtete Kampagne setzte ein kleines Rust-basiertes Linux-Implantat ein, das Persistenz herstellte und mit Angreifer-Infrastruktur kommunizierte, während es sich als legitime Systemaktivität tarnte.

Frühere Versionen tarnten sich als Kernel-Arbeitsprozess namens:

Spätere Builds übernahmen Namen wie:

fc-cache

und:

chronyd

Die fc-cache-Variante speicherte sich unter ~/.cache/fontconfig/fc-cache, fügte einen Cron-Eintrag hinzu, um zweimal pro Stunde neu zu starten, und nutzte UDP-Port 123-Verkehr, der entwickelte NTP-Kommunikation ähnelte. Sansec berichtete, dass verwandte Domains am 7. September auf 185.157.160.251 verwiesen.

Ein separater Angreifer wurde beobachtet, wie er dieselbe Schwachstelle missbrauchte, um einen kleinen PHP-Dropper bereitzustellen. Diese Nutzlast erstellte eine versteckte PHP-Web-Shell unter einem Pfad ähnlich:

pub/media/catalog/product/cache/ss_<10hex>/sync_<10hex>.php

Die Shell gab normalerweise eine HTTP-404-Antwort zurück, aber Anfragen mit dem erforderlichen X-Cache-Token-Header konnten PHP-Code über einen POST-Parameter zur Ausführung liefern.

Diese Beobachtungen zeigen, dass StyleSmuggler nicht an eine einzelne Malware-Familie oder Bedrohungsakteur gebunden ist. Mehrere Gegner können die zugrunde liegende RCE unabhängig nutzen, um ihre bevorzugten Persistenz- und Nachkompromiss-Tools bereitzustellen.

Sansec zeichnete die erste bestätigte Ausnutzung am 4. September um 22:20 UTC auf. Ein weiterer von Disrex untersuchter Magento-Server wurde etwa 50 Minuten später kompromittiert. Adobe veröffentlichte Bulletin APSB26-146 und den offiziellen Notfall-Hotfix am 7. September und bestätigte, dass die Ausnutzung bereits in freier Wildbahn stattfand.

Sansec und Disrex haben umfangreiche technische Informationen über die zugrunde liegende Kette veröffentlicht, jedoch absichtlich eine voll bewaffnete Anfrage zurückgehalten, die die Ausnutzung trivial reproduzierbar machen würde.

Nützlich CVE-2026-75650-IOCs beinhalten verdächtige Prozesse und Dateien, die mit dem Rust-Implantat in Verbindung stehen, ungewöhnliche PHP-Dateien unter Magento-Mediendirektoren, unerwartete Aktivitäten bei fehlgeschlagenen Zahlungstransaktionserinnerungen und die von Sansec identifizierte Infrastruktur. Verteidiger sollten auch nach bösartigem Bericht- oder Protokollinhalt suchen, anstatt Untersuchungen auf das Magento-Webroot zu beschränken.

CVE-2026-75650-Minderung

Adobe hat APSB26-146 als Priorität 1 eingestuft und weist betroffene Kunden an, den dedizierten VULN-39341 Hotfix sofort anzuwenden. Das offizielle Patch-Paket wird über das Magento-Repository von Adobe für betroffene Commerce- und Magento Open Source-Veröffentlichungen verteilt.

Adobe weist Kunden zusätzlich an, ihre Verschlüsselungsschlüssel nach der Anwendung des Hotfix zu rotieren . Dies ist besonders wichtig für Shops, die vor dem 7. September exponiert waren, da erfolgreiche beliebige Codeausführung Angreifern möglicherweise den Zugriff auf Anwendungsgeheimnisse und sensible serverseitige Konfigurationen ermöglicht hat.. This is particularly important for stores that were exposed before September 7 because successful arbitrary code execution may have allowed attackers to access application secrets and sensitive server-side configuration.

Die Erkennung von CVE-2026-75650 sollte daher mit drei Fragen beginnen:

1. War der Shop zwischen dem 4. September und der Installation von Adobes Hotfix aus dem Internet zugänglich?
2. Wurde VULN-39341 erfolgreich angewendet?
3. Gibt es Hinweise darauf, dass PHP- oder native Prozesse vor der Behebung gestartet wurden?

Um die Ausnutzung oder Nachkompromissaktivität von CVE-2026-75650 zu erkennen, sollten Sicherheitsteams nach folgendem suchen:

• Unerwartete Serien von E-Mails zur Erinnerung an fehlgeschlagene Zahlungstransaktionen
• Verdächtige PHP-Inhalte in Magento-Protokollen oder Dateien unter var/report/
• Berichtdateien mit ungewöhnlichen x_trace_-Zeichenfolgen
• Prozesse, die sich als [kworker/u:8:0], fc-cache oder chronyd ausgeben
• ~/.local/share/.gvfsd/ oder ~/.cache/fontconfig/fc-cache
• Verdächtige Cron-Jobs, die unbekannte Binärdateien neu starten
• Unerwartete PHP-Dateien unterhalb von pub/media/
• Web-Shells unter pub/media/catalog/product/cache/
• Ausgehender Datenverkehr zu bekannter StyleSmuggler-Infrastruktur
• Abnormaler UDP/123-Verkehr von der Magento-App-Host
• Unerwartete HTTP-Anfragen mit ungewöhnlichem Vorlagenverarbeitungsverhalten
• Neue Anwendungsbenutzer, geänderte Anmeldeinformationen oder modifizierte Serverkonfiguration nach verdächtiger Webaktivität

Administratoren sollten nicht davon ausgehen, dass das Löschen einer verdächtigen Datei aus dem Magento-Verzeichnis die Kompromittierung beseitigt. In untersuchten Vorfällen verlagerte sich die Malware außerhalb des Webroots, erzeugte cron-basierte Persistenz, lief weiterhin aus gelöschten Dateien und konnte Teile ihrer Persistenz nach der Entfernung wiederherstellen.

Der CVE-2026-75650-Minderungsprozess sollte daher die Reaktion auf Vorfälle für Shops einschließen, die vor dem Patch öffentlich zugänglich waren. Wenn Kompromittierungsindikatoren entdeckt werden, sollte der Host isoliert, forensische Beweise gesichert, bösartige Prozesse beendet, Persistenzmechanismen identifiziert, Dateisystemänderungen überprüft und Anmeldeinformationen und Geheimnisse, die vom betroffenen Server aus zugänglich sind, rotiert werden.

Besondere Aufmerksamkeit sollte auf folgende Punkte gelegt werden:

• Magento-Administrator-Anmeldeinformationen
• Verschlüsselungsschlüssel von Adobe Commerce
• Datenbank-Anmeldeinformationen
• API- und Integrationsgeheimnisse
• Zahlungs- und Drittanbieterdienstanmeldeinformationen
• SSH-Anmeldeinformationen
• Cloud- oder Hosting-Token, die vom Anwendungshost aus zugänglich sind

Sicherheitsteams sollten auch die Integrität von Magento-Anwendungsdateien und Erweiterungen validieren und ausgehende Netzwerkaktivität auf Anzeichen untersuchen, dass ein Implantat mit externer Befehls- und Kontrollinfrastruktur kommuniziert hat.

Da die ersten StyleSmuggler-Angriffe vor einem offiziellen Patch oder öffentlichen Erkennungssignaturen auftraten, stellt die bloße Bestätigung, dass ein Shop jetzt aktualisiert ist, nicht fest, dass er nie kompromittiert war. Jedes internetfähige, anfällige System, das während des Zero-Day-Fensters vom 4. bis 7. September betrieben wurde, erfordert eine historische Überprüfung.