PolyShell: warum ein gepatchtes Magento nicht reicht

Die meisten Magento-Lücken lassen sich mit einem Satz abhandeln: Patch einspielen, fertig. Bei PolyShell funktioniert dieser Satz nicht — und das ist der eigentliche Grund, warum dieser Fall eine eigene Seite verdient. Wer sein 2.4.8 lückenlos gepatcht hat, ist trotzdem betroffen, weil es für die älteren Versionszweige schlicht keinen Fix gibt.

Stand dieses Artikels: 10. September 2026. Sicherheitslagen ändern sich, Adobe kann nachliefern. Bevor du auf Grundlage dieses Textes entscheidest, wirf einen Blick auf die verlinkten Quellen — und wenn dort inzwischen etwas anderes steht als hier, gilt dort.

Was PolyShell ist

Der Name kommt von Polyglot — einer Datei, die gleichzeitig zwei Formate erfüllt. Sie fängt an wie ein Bild und enthält weiter hinten ausführbaren PHP-Code. Für eine Prüfung, die nur auf den Dateikopf und den gemeldeten Dateityp schaut, ist so etwas ein Bild. Für den Webserver ist es ein Programm.

Genau diese Lücke nutzt PolyShell aus. Magento erlaubt es, Artikeln im Warenkorb individuelle Optionen mitzugeben, darunter Optionen vom Typ „Datei". Über die REST-Schnittstelle lässt sich eine solche Datei als Base64-Block mitschicken. Die Prüfung, die dabei greift, kontrolliert Größe und gemeldeten Bildtyp — aber nicht, ob die Dateiendung zum Inhalt passt und ob die angegebene Option am Artikel überhaupt existiert.

Das Ergebnis: Die Datei landet unterhalb des öffentlichen Medienverzeichnisses auf der Platte. Ob sie sich von dort aus auch ausführen lässt, hängt an der Serverkonfiguration. Liegen die Dinge ungünstig, ist es eine fertige Webshell — und damit vollständiger Zugriff auf Shop und Datenbank, ohne dass jemand ein Passwort gebraucht hätte. Liegen sie günstig, bleibt immer noch eine fremde Datei dauerhaft in deinem Shop liegen.

Was ein Angreifer dafür braucht
Eine Gast-Warenkorb-ID und eine Artikelnummer. Beides ist öffentlich zu bekommen — ein Gast-Warenkorb lässt sich mit einem einzigen Aufruf anlegen, und die Artikelnummern stehen in deinem Shop. Keine Anmeldung, kein Kundenkonto, keine Vorbedingung. Das ist der Grund, warum die Lücke innerhalb weniger Tage automatisiert durchprobiert wurde.

Wer betroffen ist

Praktisch jeder. Betroffen sind Magento Open Source und Adobe Commerce in allen Produktivversionen — die gesamten Zweige 2.4.4 bis 2.4.8, jeweils bis zum aktuellsten Patchstand. Der Fix kam erstmals in einer Vorabversion von 2.4.9 und ist mit dessen Freigabe im Mai 2026 in die reguläre Auslieferung gewandert.

Und hier liegt der unangenehme Teil: Auf die älteren Zweige wurde er nicht zurückportiert. Kein Backport auf 2.4.8, keiner auf 2.4.7, keiner auf 2.4.6. Wer brav jeden Quartalspatch eingespielt hat und sich deshalb auf der sicheren Seite wähnte, ist es in diesem Fall nicht. Der offizielle Weg heißt: auf 2.4.9 gehen.

Für Magento 1 und OpenMage gibt es zu dieser Lücke ohnehin nichts von Adobe — dort endete der Support im Juni 2020. Wenn du noch auf Magento 1 sitzt, ist PolyShell nicht dein dringendstes Problem, sondern nur ein weiteres Argument in einer langen Liste. Wie so ein Wechsel abläuft, steht unter Magento 1 auf Magento 2 migrieren.

Prüfen, ob es dich schon erwischt hat

Weil die Lücke seit März 2026 automatisiert ausgenutzt wird, ist „patchen und weitermachen" zu wenig. Ein Shop, der über Monate offen stand, sollte auf Spuren geprüft werden — und zwar bevor du dich zurücklehnst:

• Das Verzeichnis für Datei-Optionen unterhalb des Medienordners durchsehen — dort landen die hochgeladenen Dateien. Auffällig ist alles, was auf .php, .phtml oder eine doppelte Endung hört, und alles, dessen Änderungsdatum nicht zu einer echten Bestellung passt.
• Bilddateien mit ungewöhnlicher Größe stichprobenartig im Texteditor öffnen. Steht dort irgendwo ein PHP-Block, hast du deinen Fund.
• Das Zugriffs-Log auf REST-Aufrufe zu Gast-Warenkörben durchsuchen, rückwirkend bis mindestens März 2026.
• Adminbenutzer, Integrationen und deren Tokens durchgehen — wer einmal Zugriff hatte, legt sich gern einen zweiten Weg an.
• Geplante Aufgaben und Cronjobs prüfen, ebenso Änderungen an Konfigurationswerten für Zahlungsanbieter.

Findest du etwas, ist Aufräumen der zweite Schritt und nicht der erste. Zuerst gehört gesichert, was da ist — Dateistand und Datenbank —, sonst löschst du die Spuren, die man zur Aufarbeitung braucht. Und je nachdem, welche Daten betroffen sind, läuft parallel eine Meldefrist nach DSGVO.

Was jetzt hilft

Der saubere Weg: auf 2.4.9
Es ist der einzige Weg, der die Ursache beseitigt. Er ist auch der aufwendigere, weil ein Versionssprung die Erweiterungen mitnehmen muss und in einem gewachsenen Shop selten an einem Nachmittag erledigt ist. Wer ihn aufschiebt, sollte das bewusst tun und die Zwischenzeit absichern — nicht darauf hoffen, dass doch noch ein Backport kommt.

Die Zwischenlösung: Endpunkt und Verzeichnis dichtmachen
Zwei Handgriffe auf Serverebene nehmen den Großteil des Risikos: die betroffenen REST-Aufrufe abweisen, bevor Magento sie überhaupt sieht, und die Ausführung von PHP im Medienverzeichnis unterbinden. Der zweite Punkt gehört ohnehin in jede Magento-Installation, unabhängig von dieser Lücke. Eine Web Application Firewall kann den ersten Teil übernehmen, wenn eine im Einsatz ist.

Brauchst du die REST-Schnittstelle im Alltag gar nicht — und das trifft auf mehr klassische Shops zu, als man denkt —, ist das ein guter Anlass, sie grundsätzlich zu schließen statt nur diesen einen Endpunkt. Was dabei zu beachten ist, steht im Artikel Die Magento-REST-API ist an — auch wenn du sie nicht nutzt; die Absperrung selbst übernimmt unser REST-Blocker.

Von inoffiziellen Patches aus der Community gibt es einige, und manche davon sind ordentlich gemacht. Sie ersetzen aber weder die Prüfung durch jemanden, der deinen Shop kennt, noch den späteren Versionssprung. Wenn du einen einspielst, notiere das — sonst überschreibt ihn das nächste reguläre Update kommentarlos.

Die Lehre daraus

PolyShell ist unangenehm, weil er eine Annahme kippt, auf der viele Wartungsverträge stehen: dass „aktueller Patchstand" gleichbedeutend mit „abgesichert" ist. Ist es nicht. Ein Versionszweig, der keine neuen Funktionen mehr bekommt, bekommt irgendwann auch nicht mehr jeden Fix — und das erfährt man in der Regel dann, wenn es unpassend kommt.

Praktisch heißt das: Der Versionssprung gehört eingeplant, bevor er dringend wird. Zwei Zweige hinter der aktuellen Version zu liegen ist kein Zustand, den man aussitzt, sondern einer, den man mit einem Termin versieht. Das ist unbequemer als ein Quartalspatch, aber deutlich billiger als die Alternative.

Quellen

• Sansec: PolyShell — unrestricted file upload in Magento and Adobe Commerce — die technische Erstveröffentlichung vom 17. März 2026, inklusive Hinweisen zur Spurensuche.
• Adobe Security Bulletin APSB25-94 — das Bulletin, unter dem Adobe den Fall führt, mit den betroffenen Versionen.
• Akamai: Magento PolyShell — The Latest Magento Threat — Einordnung der Angriffskette und Beobachtungen aus dem laufenden Betrieb.
• Searchlight Cyber: Unauthenticated File Upload to RCE — ausführliche Analyse des Ablaufs im Code.

Häufige Fragen