Plex2Shell heißt eine Exploit-Kette, die aus vier Schwachstellen in Plex Media Server eine unauthentifizierte Remote-Code-Execution macht. Betroffen sind selbst betriebene Installationen bis einschließlich Version 1.43.3.10828. Seit dem 17. Oktober 2026 wird die Kette nachweislich gegen mindestens einen Linux/Docker-Honeypot ausgenutzt und lädt dort einen XMRig-Krypto-Miner sowie Proxy-Software nach. Wer noch nicht auf 1.43.3.10861 aktualisiert hat, sollte das zeitnah nachholen — der Handlungsdruck ist real.
Was Plex2Shell auf Plex-Servern ermöglicht
Vier einzeln unterschiedlich schwerwiegende Lücken ergeben in Kombination einen vollständigen Zugriff ohne jede Anmeldung. Der Einstieg läuft über CVE-2026-96652: eine unauthentifizierte Server-Side Request Forgery über den Endpunkt /player/timeline, genauer über den Parameter protocol=. Von dort aus pivotiert CVE-2026-96654 auf die Loopback-Schnittstelle — eine wirkungslose Auth-Prüfung plus eine Injection über searchOne identifier= macht es möglich.
Der dritte Schritt setzt formal bereits Owner-Rechte voraus: CVE-2026-96655 kombiniert eine Transcoder-SSRF mit einem Dateischreibzugriff auf beliebige Pfade über dump-yuv. Erreichbar wird dieser Schritt erst, weil die Kette zuvor die Authentifizierung über den Loopback-Pivot aushebelt. Den Abschluss bildet CVE-2026-96656, die eigentliche Codeausführung: Sie nutzt das Nachladen eines unsignierten Codec über dlopen im Codecs-Verzeichnis.
Für die Kette kursieren zwei Einstufungen: CVSS 3.1 mit 10.0 sowie 9.8. Beide Werte beziehen sich auf das Zusammenspiel der vier Lücken, nicht auf eine Einzellücke. Eine offizielle Einstufung von Plex selbst liegt in den vorliegenden Quellen nicht vor — wer die Kette in einem Vulnerability-Management priorisieren will, sollte den höheren Wert ansetzen und die Abweichung dokumentieren.
Honeypot-Logs: XMRig und Proxy-Software nachgeladen
Die Beobachtungen vom 17. Oktober 2026 stammen von einem Linux-basierten Plex-Media-Server-Honeypot in Docker. Ein erster Zustellversuch kam von 45.194.92[.]222, weitere von 91.92.40[.]202 und 176.65.139[.]228. Nach dem Freischalten ausgehender Verbindungen lud der Host zwei Dateien namens docker und x von 217.60.194[.]116 nach und startete anschließend einen XMRig-Miner.
Später fiel ein Prozess namens myawesomeproxy mit Traffic zu proxystream[.]st auf. Das Programm selbst weist darauf hin, dass der Internet-Traffic des Geräts extern genutzt wird — der kompromittierte Server wird also nicht nur als Rechenknecht, sondern als Teil eines Proxy-Netzwerks interessant. Diese IP-Adressen sind Honeypot-Beobachtungen und belegen keinen bestimmten Täterkreis.
Forensisch ist der Fall gut dokumentiert: Es liegen PCAP-Mitschnitte der Ausnutzung vor, darunter eine interaktive Reverse Shell sowie Einzelaufrufe von id und hostname. Als Testziel diente linuxserver/plex:1.42.2; im Exploit-Code tauchen die Ports 8952 (Token), 8933 (Carrier) und 9001 (lport) sowie das Host-Muster 127.0.0.1.<ip>.sslip.io auf. Die Waffenisierung erfolgte innerhalb von Stunden nach Veröffentlichung der technischen Details.
Von „Leak" kann keine Rede sein
Der Exploit war öffentlich verfügbar, aber nicht durchgesickert. Die vier Lücken wurden am 27. Juli 2026 vertraulich an Plex gemeldet, am 4. August 2026 bestätigt und über ein Bug-Bounty honoriert. Am 1. September 2026 wurden Sicherheitsupdates angekündigt, für Plex Media Server 1.43.3 und Plex Desktop 1.115.0. Erst danach erschien die vollständige Kette samt Python-PoC, Payload-Quellcode für Linux und Windows sowie technischem Write-up. Eine undichte Stelle ist nicht dokumentiert.
Wer den Code nachbauen will, braucht Python 3.8 oder neuer, ffmpeg und gcc — für Windows-Payloads x86_64-w64-mingw32-gcc. Entscheidende Voraussetzung bleibt, dass der Angreifer-Host vom Ziel aus erreichbar ist, sowohl für den Media-Fetch als auch für die Reverse-Shell-Verbindung. Ein vom offenen Internet abgeschotteter Server senkt das Risiko deutlich, hebt es aber nicht auf.
Betroffen sind Linux, Docker und Windows
Die Kette trifft Plex Media Server in allen im PoC abgedeckten Varianten: native Linux-Pakete (.deb/.rpm), Linux-Docker-Container und Windows-Installationen. Als gefixt gilt Version 1.43.3.10861. Ein funktionaler Workaround ist in den vorliegenden Quellen nicht dokumentiert — außer dem Update bleibt als Sofortmaßnahme nur, die Instanz vom Internet abzuschotten.
Ein Punkt, der in vielen Heiminstallationen untergeht: NAS-Nutzer müssen das Update gegebenenfalls manuell einspielen, weil der Auto-Update-Mechanismus dort nicht überall greift. Wer seinen Plex-Server auf einem Synology-, QNAP- oder vergleichbaren Gerät betreibt, sollte die installierte Version aktiv prüfen statt auf einen automatischen Hinweis zu warten.
Fazit: Update, dann Spuren suchen
Das Update auf 1.43.3.10861 ist die einzige belastbare Gegenmaßnahme — und es ist seit Wochen verfügbar. Wer in den vergangenen Tagen einen auffällig hoch ausgelasteten Plex-Host bemerkt hat, sollte nach XMRig-Prozessen, einem Prozess namens myawesomeproxy sowie ausgehenden Verbindungen zu proxystream[.]st oder 217.60.194[.]116 suchen und den Server im Zweifel als kompromittiert behandeln.
Ein Angriffsmaßstab lässt sich daraus nicht ableiten: Belegt ist die Ausnutzung eines Honeypots, nicht die Zahl produktiver Kompromittierungen. Das mindert den Handlungsdruck nicht — es verhindert nur, die eigene Lage an einer Statistik zu messen, die es nicht gibt. Wer bislang nicht gepatcht hat, hat seit dem 1. September 2026 Zeit gehabt; viel länger sollte die Frist nicht werden.
Quellen
- Exploit-Code geleakt: Angreifer schleusen Malware auf Plex-Server
- GitHub – gmh5225/plex2shell
- Mallory – Plex2Shell RCE Chain Exploited to Deploy XMRig and Proxy Software
- GitHub – BoredHackerBlog/plex2shell_pcap
- SecurityWeek – Plex2Shell Exploit Chain Weaponized Against Plex Servers Hours After Disclosure