Eine als PolyShell bezeichnete Schwachstelle trifft derzeit alle aktuellen Versionen von Magento Open Source und Adobe Commerce 2.x. Die Luecke erlaubt es Angreifern, ohne Anmeldung beliebige Dateien auf den Server zu laden – die Basis fuer Remote Code Execution (RCE), gespeicherte XSS-Angriffe und im Extremfall die Uebernahme von Admin- und Kundenkonten.
Kritische Magento-Sicherheitsluecke PolyShell und Patch-Status bei Adobe
Entdeckt wurde PolyShell von den Sicherheitsspezialisten von Sansec, die sich seit Jahren auf Angriffe gegen E-Commerce-Plattformen konzentrieren. Adobe hat die Schwachstelle bestaetigt und ein Fix in den Security-Bulletin APSB25-94 aufgenommen. Laut Sansec ist der Patch aktuell nur in der Vorrelease-Version 2.4.9 verfuegbar; eine eigene Aktualisierung fuer produktive 2.x-Installationen steht noch aus.
Dieses Zeitfenster ist sicherheitskritisch: Sobald ein Exploit-Konzept oeffentlich oder in Untergrundforen geteilt wird, steigt die Zahl der Angriffe erfahrungsgemaess sprunghaft. Bei Magento-Schwachstellen der Vergangenheit lagen zwischen Offenlegung und massenhaftem Missbrauch oft nur wenige Tage.
Wie PolyShell funktioniert: ungepruefter Datei-Upload ueber REST API
REST-API-Endpunkt fuer Custom-Options-Dateien
Die technische Ursache liegt im REST API von Magento, das das Hinzufuegen von Produkten mit individuellen Optionen zum Warenkorb steuert. Fuer Optionen des Typs file akzeptiert die API ein Objekt file_info, das unter anderem Base64-kodierten Dateiinhalt, MIME-Typ und Dateinamen enthaelt. Nach dem Dekodieren speichert Magento die Datei in pub/media/custom_options/quote/ auf dem Server.
Entscheidend ist, dass dieser Upload ohne Authentifizierung moeglich ist. Ein korrekt formatierter REST-Request reicht aus, um Dateien im Dateisystem des Shops zu platzieren. Ob daraus eine ausnutzbare Sicherheitsluecke wird, haengt von der Konfiguration des Webservers und vom Umgang mit diesen Dateien ab.
Polyglot-Dateien, Webshells und gespeicherte XSS
Der Name PolyShell verweist auf polyglot files – Dateien, die von unterschiedlichen Parsern als verschiedene Formate akzeptiert werden, etwa gleichzeitig als Bild und als Script. Wird der Webserver unsicher konfiguriert, kann eine als Bild hochgeladene Datei bei direktem Aufruf als Code interpretiert und ausgefuehrt werden.
Ein typischer Angriff sieht so aus: Der Angreifer sendet einen API-Request, der das Hinzufuegen eines Produkts simuliert, und uebergibt in file_info einen Base64-kodierten Polyglot-Inhalt. Magento legt die Datei in pub/media/custom_options/quote/ ab. Ist die Medienstruktur dann so konfiguriert, dass dort .php oder andere Skript-Typen ausgefuehrt werden koennen oder Content-Types fehlerhaft behandelt werden, wird aus der Datei eine Webshell oder ein persistent eingebettetes XSS-Payload.
Massendefacement von Magento-Shops durch „Typical Idiot Security“
Parallel zur Offenlegung von PolyShell meldete Netcraft eine breite Defacement-Welle gegen Magento-Seiten. Seit dem 27. Februar 2026 wurden auf mehr als 7.500 Websites Textdateien mit einer identischen „Signatur“ abgelegt, meist unter dem Pseudonym Typical Idiot Security, das auch in der Hackerdatenbank Zone-H auftaucht.
Betroffen waren unter anderem Subdomains und regionale Praesenzen namhafter Marken wie Asus, BenQ, Citroën, Diesel, FedEx, Fiat, Lindt, Toyota, Yamaha sowie Regierungs- und Universitaetsdomains. Ein Defacement wirkt oft vergleichsweise harmlos, zeigt aber, dass Angreifer Schreibzugriff auf das Webverzeichnis haben – ein zentrales Indiz fuer tiefergehende Kompromittierungen.
Netcraft vermutet den Einsatz von unauthentifizierten Dateiupload-Schwachstellen, die strukturell mit PolyShell verwandt sind. Die Kampagne erinnert an die 2025 bekannt gewordene Magento-Luecke SessionReaper, bei der unsichere Session- und Upload-Mechanismen missbraucht wurden.
Risikoanalyse: Folgen von RCE und gespeicherter XSS in Online-Shops
Remote Code Execution in einem E-Commerce-Kontext bedeutet, dass Angreifer nahezu beliebige Befehle auf dem Server ausfuehren koennen: das Nachinstallieren von Backdoors, das Anlegen versteckter Admin-Accounts, das Manipulieren von Zahlungs-Skripten oder das Umleiten von Transaktionen auf eigene Konten.
Gespeicherte XSS zielt dagegen primär auf Browser und Sitzungen der Benutzer. Wird Schadcode in Templates, Admin-Interfaces oder Produktseiten injiziert, koennen Angreifer Sitzungs-Cookies stehlen, Administratorenkonten uebernehmen, Keylogger im Browser platzieren oder Kreditkartendaten abfischen – ohne weiteren Serverzugriff zu benoetigen.
Sofortmassnahmen gegen PolyShell und aehnliche Angriffe
1. Zugriff auf Upload-Verzeichnisse beschraenken. Direktaufrufe auf pub/media/custom_options/ sollten auf Webserver-Ebene (nginx, Apache) blockiert werden, etwa mit deny all oder entsprechender Zugriffskontrolle. Zudem muss sichergestellt sein, dass in Medienverzeichnissen keine Skripte ausgefuehrt werden.
2. Medienverzeichnisse auf Webshells scannen. Betreiber sollten pub/media/custom_options/quote/ und weitere Medienpfade nach ungewoehnlichen Dateien durchsuchen: ungewoehnliche Endungen, kryptische Dateinamen oder Scriptcode in vermeintlichen Bildern. Spezialisierte Websecurity-Scanner und aktuelle Virenscanner unterstuetzen bei der Erkennung.
3. Webserver-Konfiguration haerten. In allen Upload- und Medienverzeichnissen sollten .php, .phtml oder andere ausfuehrbare Dateitypen grundsaetzlich deaktiviert werden. Content-Types muessen serverseitig korrekt gesetzt werden; Angreifer sollten sie nicht ueberschreiben koennen.
4. REST API einschränken und ueberwachen. Kritische Endpunkte sollten, wo immer moeglich, per IP-Whitelist, API-Gateway oder Web Application Firewall (WAF) geschuetzt werden. Ausfuehrliche Logs helfen dabei, auffaellige Upload-Anfragen fruehzeitig zu erkennen und zu blockieren.
5. Update-Strategie beschleunigen. Sobald Adobe stabile Patches fuer Magento / Adobe Commerce bereitstellt, sollten diese nach kurzem Test in einer Staging-Umgebung ohne Verzoegerung in Produktion ausgerollt werden. Verzoegerungen bei kritischen Sicherheitsupdates gehoeren zu den haeufigsten Ursachen erfolgreicher Shop-Kompromittierungen.
PolyShell und die parallele Defacement-Kampagne unterstreichen, wie gefaehrlich ungepruefte und unauthentifizierte Dateiuploads im E-Commerce sind. Betreiber von Magento- und Adobe-Commerce-Instanzen sollten ihre Bedrohungsmodelle aktualisieren, Webserver-Konfigurationen konsequent absichern, regelmaessige Security-Audits etablieren und Sicherheitsbulletins von Sansec, Adobe und Netcraft eng verfolgen. Wer jetzt in Härtung, Monitoring und schnelle Patch-Prozesse investiert, reduziert das Risiko erheblich, in der naechsten Angriffswelle zu den kompromittierten Shops zu gehoeren.
