CISA stuft PolyShell als ausgenutzt ein, während die Magento-Kampagne Hunderte Shops trifft

Eine Schwachstelle, die Adobe im Juli gepatcht hat, erzeugt im November weiterhin Sicherheitsvorfälle. Am 27. Oktober nahm die US-Cybersecurity-Behörde CISA CVE-2026-48356 in ihren Katalog bekannter ausgenutzter Schwachstellen auf und gab Bundesbehörden bis zum 10. November Zeit, sie zu beheben. Die Lücke, die das Sicherheitsunternehmen Sansec PolyShell nennt, ist ein nicht authentifizierter Datei-Upload in Adobe Commerce und Magento, der zu Remote-Code-Ausführung führen kann. Das NVD bewertet sie mit 9,3 von 10.

Zum Weiterlesen: Adobe Commerces Zero-Day „StyleSmuggler“ traf Shops drei Tage vor dem Fix · Microsofts Patchday im Oktober 2026 stellt mit 1.407 Korrekturen einen Rekord auf.

Die KEV-Aufnahme ist die formale Anerkennung einer Kampagne, die seit Monaten läuft. Sansec sagt, Angreifer hätten die Lücke genutzt, um einen schädlichen Loader auf 953 Onlineshops zu platzieren, eingeschleust über einen Magento-CMS-Block. Das Unternehmen warnte im März erstmals vor der Schwachstelle, beobachtete, wie Massenscans innerhalb von Tagen begannen, und verfolgte die Kampagne durch Adobes Patch und den Backport im Juli. Die Shops, die nicht aktualisiert haben, sind weiterhin gefährdet.

The Hacker News berichtete, der Loader sei darauf ausgelegt, eine vom Angreifer kontrollierte Nutzlast abzurufen und auszuführen, doch es sei keine Malware der nächsten Stufe gefunden worden. Diese Lücke zählt. Sie bedeutet, dass das Ziel der Kampagne nicht öffentlich bekannt ist. Es könnte ein Payment-Skimmer sein, ein Weiterleitungsschema, ein Sammler von Zugangsdaten oder eine Vorbereitungsschicht für etwas anderes. Die Aktivität wird als mindestens seit Juli 2025 andauernd eingeschätzt.

Die Lücke: ein Upload-Feld, das dem Client vertraut

PolyShell steckt in der REST-API von Magento. Wenn ein Produkt eine benutzerdefinierte Option vom Typ Datei hat, akzeptiert die API ein eingebettetes Dateiobjekt mit base64-kodierten Daten, einem MIME-Typ und einem Dateinamen und schreibt die Datei dann in pub/media/custom_options/quote/ auf dem Server. Sansec fand drei fehlende Prüfungen:

• Keine Prüfung der Options-ID. Die übermittelte Options-ID wird nie gegen die tatsächlichen Optionen des Produkts verifiziert.
• Keine Prüfung des Optionstyps. Die Upload-Logik läuft, unabhängig davon, ob das Produkt eine Dateioption hat.
• Keine Einschränkung der Dateiendung. Endungen wie .php, .phtml und .phar werden nicht blockiert.

Die einzige Validierung ist eine Prüfung des Bildheaders mit getimagesizefromstring, die eine Polyglot-Datei bestehen kann, während sie weiterhin ausführbares PHP enthält. Die gefährlichsten Endpunkte sind die anonymen Gast-Warenkorb-Routen POST /V1/guest-carts/:cartId/items und PUT /V1/guest-carts/:cartId/items/:itemId, die keine Authentifizierung erfordern. GraphQL-Mutationen nutzen einen anderen Codepfad und sind nicht verwundbar.

Ob die hochgeladene Datei ausgeführt werden kann, hängt vom Webserver ab. Standard-nginx-Konfigurationen geben in einigen Versionen .php-Dateien an FastCGI weiter, und Apache-Installationen ohne php_flag engine 0 können dasselbe tun. Sansec sagt, viele Shops liefen mit eigenen Konfigurationen ihrer Hoster, weshalb die Auswirkung variiert. Selbst wenn die Ausführung blockiert ist, bleibt die Datei auf der Festplatte. Eine spätere Konfigurationsänderung, Migration oder ein Serverwechsel kann sie wieder gefährlich machen.

Die Kampagne: 953 Shops und eine hartnäckige Hintertür

Sansecs Zeitlinie beginnt am 16. März 2026, als das Unternehmen PolyShell-Schutz in sein Produkt Shield einbaute. Am nächsten Tag veröffentlichte es eine Warnung. Die ersten Angriffe erschienen am 19. März, und automatisierte Massenscans begannen am 23. März. Bis zum 24. März erklärte Sansec, bei 56,7 Prozent aller geschützten Shops sei schädlicher PHP-Code hochgeladen worden. Bis zum 30. März waren 79,5 Prozent angegriffen worden. Bis zum 14. April lag die Zahl bei 82 Prozent.

Die Angreifer hörten nach dem ersten Upload nicht auf. Sansec fand eine zweite Hintertür namens accesson.php, verteilt über mehrere Verzeichnisse auf kompromittierten Shops, darunter var/assets/images/, app/assets/images/, vendor/assets/images/ und pub/assets/images/. Die Kopien sind eine Persistenzstrategie. Ein Verzeichnis zu bereinigen, entfernt die anderen nicht. Die Hintertür meldet sich per Beacon, indem sie eine feste Zahl ausgibt, akzeptiert Befehle über ein cookie-authentifiziertes PHP-Eval und kann weitere Dateien hochladen.

Die letzte Schicht ist JavaScript. Sansec fand einen obfuskierten Loader, der in CMS-Seiten und statische Blöcke eingeschleust wurde. Der Loader speichert eine Nutzlast im localStorage des Browsers, sodass sie Seitenneuladungen übersteht, selbst wenn die externe Quelle ausfällt, und ruft eine neue Nutzlast von Domains ab, darunter lanhd6549tdhse[.]top. Dieses Design erschwert die Bereinigung: Das Entfernen der serverseitigen Injektion stoppt die Infektion neuer Besucher, bereinigt aber keine Browser, die die Nutzlast bereits zwischengespeichert haben.

PolyShell ermöglicht es Angreifern, über die REST-API ausführbare Dateien auf jeden Magento- oder Adobe-Commerce-Shop hochzuladen.

Warum ein Patch im Juli es nicht beendete

Adobe behob die zugrunde liegende Schwachstelle in Magento 2.4.9, veröffentlicht am 12. Mai 2026, und spielte den Fix am 14. Juli über APSB26-73 in unterstützte Release-Zweige zurück. Das ist die richtige Reihenfolge. Es ist auch der Punkt, an dem das Patchen üblicherweise langsamer wird.

Die Shops, die das Update eingespielt haben, sind nicht mehr für den Upload anfällig. Die anderen schon. Magento- und Adobe-Commerce-Installationen werden oft von Agenturen und Hostern angepasst, was Upgrades langsamer und riskanter macht als ein routinemäßiges Softwareupdate. Ein Händler kann einen Patch verzögern, weil ein eigenes Modul vom alten Code abhängt, weil das Upgrade-Fenster vor einem Verkaufszeitraum eng ist oder weil niemand die Aufgabe verantwortet. Die KEV-Aufnahme soll diese Wahlfreiheit für Bundesbehörden beseitigen. Private Händler bindet sie nicht.

Das Ergebnis ist ein langer Schwanz verwundbarer Shops, den Angreifer automatisch scannen können. Sansecs Daten zu Massenscans zeigen, wie schnell dieser Schwanz gefunden wird. Die 953 Shops der Loader-Kampagne sind der sichtbare Teil. Die Zahl der Shops, die geprüft, aber nicht kompromittiert wurden, ist größer, und die Zahl der weiterhin ungepatchten ist größer noch.

Was Shop-Betreiber tun sollten

Der erste Schritt ist, die Version von Magento oder Adobe Commerce zu bestätigen. Shops auf 2.4.9 oder einem Release-Zweig mit dem APSB26-73-Backport haben den Fix. Shops auf älteren Versionen nicht.

Der zweite ist, den Upload-Pfad am Webserver zu blockieren. Sansecs nginx-Regel verweigert jeden Zugriff auf pub/media/custom_options/, bevor ein .php-Location-Block greift. Das Apache-Äquivalent ist eine .htaccess-Datei in diesem Verzeichnis mit php_flag engine 0 und Deny from all. Das Blockieren der Ausführung stoppt den Upload nicht, entfernt aber den einfachsten Weg zur Codeausführung, während der Patch eingespielt wird.

Der dritte ist, nach einer Kompromittierung zu suchen. Sansec empfiehlt, in pub/media/custom_options/ nach .php-, .phtml- oder .phar-Dateien und im gesamten Document Root nach accesson.php zu suchen. Shop-Betreiber sollten außerdem CMS-Seiten und statische Blöcke nach Verweisen auf die Skimmer-Domains durchsuchen und Server-Logs auf Anfragen an die Gast-Warenkorb-Endpunkte aus unerwarteten Quellen prüfen.

Der vierte ist, Zugangsdaten zu rotieren. Eine Hintertür, die Dateien hochladen und Code ausführen kann, wurde möglicherweise genutzt, um Konfigurationsdateien, Zahlungsschlüssel oder Admin-Sitzungen zu lesen. Eine Datei zu entfernen ist nicht dasselbe, wie den Angreifer zu vertreiben.

Worauf zu achten ist

Die KEV-Frist vom 10. November wird eine Patch-Compliance-Zahl für Bundesbehörden erzeugen. Für den Einzelhandel wird sie keine erzeugen. Das nützlichere Signal ist, ob Sansec und andere Incident-Responder nach der Frist neue Loader-Infektionen melden. Wenn die Kampagne im gleichen Tempo weiterläuft, ist das Problem die installierte Basis. Eine Lücke, die leicht auszunutzen und langsam zu patchen ist, bleibt ein Ziel, auch nachdem der Hersteller einen Fix ausliefert.

Adobe hat keine Schätzung veröffentlicht, wie viele Shops ungepatcht bleiben. Sansecs Prozentzahlen beschreiben die eigene geschützte Kundenbasis, nicht den gesamten Markt. Das begrenzt, wie weit die Zahlen verallgemeinert werden können, ändert aber nicht die Richtung. Eine Lücke, die leicht auszunutzen, automatisiert zu scannen und langsam zu patchen ist, bleibt ein dauerhaftes Ziel, auch nachdem der Hersteller einen Fix ausliefert.

Vorbehalte

• 953 ist die Zahl der Shops mit dem Loader. Es ist keine bestätigte Zahl der Shops, deren Kundendaten gestohlen wurden.
• Es wurde keine Malware der nächsten Stufe gefunden. Ziel, Nutzlast und Urheberschaft der Kampagne sind unbestätigt.
• Die Prozentzahlen sind Anteile der von Sansec geschützten Shops. Sie sind keine Anteile aller Magento- oder Adobe-Commerce-Shops.
• Die Frist für Bundesbehörden gilt für US-Bundesbehörden. Private Händler haben keine vergleichbare gesetzliche Frist.
• Adobe patchte die Lücke im Mai und spielte den Fix im Juli zurück. Ungepatchte Shops bleiben verwundbar; gepatchte nicht.
• Der Stand der Cloudflare-WAF kann sich geändert haben. Sansec merkte an, Cloudflare habe zum Zeitpunkt der Analyse keine PolyShell-spezifische Regel veröffentlicht; das Unternehmen lieferte jedoch eine Notfallregel für die separate Brotli-Lücke.
• Die Zeitlinie ist Sansecs. Adobe und CISA haben keine vollständige Kampagnengeschichte veröffentlicht.

Die KEV-Aufnahme macht aus einer monatelangen Schwachstelle eine Frist. Für die Shops, die noch ungepatchtes Magento betreiben, hat das Scannen nie aufgehört.

Titelbild: Der Adobe-Welthauptsitz in San Jose, Kalifornien. Foto von Coolcaesar, CC BY-SA 4.0, via Wikimedia Commons, auf 16:9 zugeschnitten.