Heulende Lüfter im Wohnzimmer: Ein versteckter Krypto-Miner im Hintergrund
In der Ecke eines ruhigen Wohnzimmers drehten die Lüfter eines leisen Heimkino-PCs plötzlich die ganze Nacht hindurch mit voller Drehzahl. Das System diente eigentlich nur dem Streaming von 4K-Filmen und lief im Alltag mit minimaler Last. Als der Besitzer das Dashboard öffnete, zeigte die CPU-Auslastung seit Tagen durchgehend 100 Prozent an.
Zwei unbekannte Prozesse verbrauchten Tag und Nacht massive Rechenleistung: Ein als Netzwerk-Proxy getarnter Dienst namens myawesomeproxy und ein Krypto-Mining-Programm namens mylovelyminer. Der Besitzer hatte weder unbekannte Pakete heruntergeladen, noch war die Weboberfläche ungeschützt – ein starkes, individuelles Passwort sicherte den Zugang.
Die Ursache lag in der Medienserver-Software Plex Media Server. Sicherheitsforscher legten eine Remote-Code-Execution-Kette namens plex2shell offen (CVE-2026-96652, -96654, -96655, -96656). Betroffen sind Version 1.43.2 und ältere Releases. Angreifer aus dem Internet benötigten keinerlei Zugangsdaten, um den Rechner über gezielt manipulierte Anfragen vollständig zu kapern.
Abbildung: Protokoll eines Honeypots, das den Download schädlicher Payloads durch automatisierte Skripte der Angreifer zeigt. Quelle: BoredHackerBlog.
Ungeprüfte Callback-Adressen verleiten den Server zum Selbstangriff
Viele lokale Dienste basieren auf einer bequemen Grundannahme: Anfragen von localhost gelten standardmäßig als vertrauenswürdig. Um internen Verifizierungsaufwand zu sparen, hatte Plex die Filterregeln für Loopback-Verbindungen stark gelockert. Genau dieses Vertrauensmodell wurde zum Einfallstor. Gelingt es einem externen Angreifer, den Server dazu zu bringen, sich selbst anzugreifen, fällt die interne Verteidigungslinie sofort in sich zusammen.
Die Schwachstelle verbarg sich in der Timeline-Schnittstelle /player/timeline, über die Player ihren Wiedergabestatus melden. Eigentlich verlangt der Endpunkt einen X-Plex-Token-Header. Der serverseitige Code prüfte jedoch lediglich mit der Methode hasParam(), ob der Header existierte. Dessen Gültigkeit oder Authentizität wurde nie geprüft – beliebige Dummy-Zeichen genügten.
Nach Passieren dieser Barriere sendet der Server Ereignisbenachrichtigungen an die Adresse des Players zurück. Die URL wurde über boost::format("%1%://%2%:%3%") zusammengesetzt. Der Protokollparameter protocol unterlag dabei keinerlei Formatprüfung oder Zeichenbereinigung.
Der Angreifer schleuste eine vollständige URL samt Loopback-Adresse in diesen Parameter ein. Plex schickte daraufhin einen HTTP-POST-Request direkt an den eigenen internen Management-Port. Auf Transportebene stammte die Verbindung von der echten IP 127.0.0.1. Der Angreifer hatte den vertrauenswürdigen lokalen Status erlangt.
Fehlerhafter Präfix-Abgleich händigt Administrator-Token aus
Als lokaler Anrufer getarnt, steuerte der Angreifer die interne Plugin-Schnittstelle /system/agents/* an. Da der Ursprung auf dem Loopback-Interface lag, übersprang der Endpunkt die Authentifizierung. Im Server-Skript agentservice.py war zwar eine Whitelist für die Funktion searchOne vorgesehen, doch ein Programmierfehler setzte sie außer Kraft.
Über der Funktion lag der Mutex-Decorator @lock. Dieser leitete den Rückgabewert der zugrundeliegenden inner()-Funktion nicht weiter. Wurde die Ausführung durch die Whitelist-Prüfung abgebrochen, verwarf der Decorator den Rückgabewert einfach. Die Schutzfunktion lief ins Leere.
Gleichzeitig fehlte dem Parameter identifier jede Filterung. Ein Fragezeichen ? ermöglichte das Anhängen beliebiger Query-Parameter, während eine Raute # den vordefinierten Pfad /messaging/... einfach abschnitt. Damit stand die zweite Lücke.
Als Nächstes visierte der Angreifer globale Administratorrechte an. Im Plugin-Framework von Plex existierte eine Komfortfunktion: Ausgehende Anfragen an Adressen, die mit 127.0.0.1 beginnen, versah das System automatisch mit dem administrativen Token local-*. Da das Framework nur einen simplen String-Präfixabgleich nutzte und Hostnamen-Grenzen ignorierte, erfüllten auch Ziele wie 127.0.0.1.evil.com die Bedingung.
Mithilfe des Wildcard-DNS-Dienstes sslip.io erzeugte der Angreifer die Domain 127.0.0.1.10-0-0-9.sslip.io. Sie passte auf die Präfix-Regel, löste aber über das öffentliche DNS direkt zur IP-Adresse des Angreifers (10.0.0.9) auf. Plex übermittelte das Administrator-Token bereitwillig an den Angreifer, womit die dritte Schwachstelle griff.
Abbildung: Echtzeit-Protokoll eines Forschers, das automatisierte Scans und Ausnutzungsversuche bösartiger IP-Adressen dokumentiert. Quelle: BoredHackerBlog.
Schadcode als Videobild getarnt: Der Transcoder als Dateischreiber
Mit dem Administrator-Token besaß der Angreifer das Recht, globale Server-Einstellungen zu modifizieren. Plex nutzt einen integrierten Transcoder, um Medien für unterschiedlichste Endgeräte aufzubereiten. Die x264-Encoding-Komponente bot Debug-Parameter, in die der Angreifer eigene Optionen einschleusen konnte: TranscoderH264Options=dump-yuv=<Pfad>:qp=0.
Der Parameter dump-yuv ruft intern fopen(Pfad, "w") auf und schreibt unkomprimierte Video-Rohframes direkt in den angegebenen Pfad. Setzt man den Quantisierungsparameter qp auf 0, arbeitet der Encoder verlustfrei, sodass Pixelwerte bitgenau erhalten bleiben. Der Angreifer kompilierte vorab eine minimale Shared Library im ELF-Format (.so), die lediglich einen Initialisierungs-Konstruktor enthielt.
Die Binärdaten dieser Bibliothek schrieb er Byte für Byte in die Helligkeitsebene (Y-Ebene) des ersten Frames eines MP4-Videos. Nach außen hin entstand ein völlig unauffälliges, abspielbares H.264-Video.
Über das Admin-Token forderte der Angreifer eine Transkodierung an und verwies mit dem Parameter path auf eine eigene Remote-Playlist item.xml. Plex lud das Trägervideo herunter und startete den Transcoder. Sobald das erste Einzelbild dekodiert war, griff die Debug-Routine. Die in den Pixeln versteckte Schadbibliothek wurde von der Transcoding-Engine direkt in das interne Codecs-Verzeichnis geschrieben.
Fehlende Signaturprüfung: Unsignierte Bibliotheken übernehmen die Kontrolle
Die Ablage auf der Festplatte genügt nicht – das System muss die Datei auch laden. Die mitgelieferte Plex-Komponente libavutil.so.58 ruft beim Start des Transcoders die Funktion avpriv_load_new_libs auf. Diese durchsucht das Codecs-Verzeichnis und führt für jede Datei mit der Endung .so direkt dlopen(path, RTLD_NOW) aus.
Diese Laderoutine verzichtete auf elementare Sicherheitsprüfungen: Weder wurden Namenspräfixe kontrolliert, noch Ausführungsrechte verlangt oder digitale Signaturen validiert. Selbst bei einfachen Leserechten wurde die Datei anstandslos in den Speicher geladen.
Nach den Spezifikationen für ELF-Bibliotheken führt dlopen Konstruktoren aus DT_INIT_ARRAY vor jedem Symbolaufruf automatisch aus. Der Konstruktor rief direkt fork() und execve() auf und öffnete eine Reverse Shell unter dem Daemon-Benutzer uid=1000(plex). Damit war die Exploit-Kette vollständig.
LLMs senken die Hürde für Exploit-Ketten: Heimische Edge-Geräte im Visier
Der Ablauf von der Entdeckung bis zum Fix war straff getaktet: Am 27. Juli 2026 meldete der Sicherheitsforscher die Schwachstelle. Am 4. August bestätigte Plex das Problem und zahlte eine Prämie aus. Am 23. September wurden vier CVEs zugeteilt, und am 16. Oktober folgten Details und Patches.
Direkt nach der Veröffentlichung setzten Angriffe in freier Wildbahn ein. Honeypots registrierten automatische Scans von den Adressen 45.194.92.222, 91.92.40.202 und 176.65.139.228. Schadprogramme wurden vom Server 217.60.194.116 verteilt.
Sichergestellte Proben umfassten ein Container-Image mit dem Hash 5712ef510481f15fe8b18fdd10b73026d57cb3d9d151878a692358b99a464441 sowie eine mit UPX gepackte Binärdatei 68938fb428f2bcfef4ede62f7b29cd0f15f37ed59e94462c099f2ca64e36baa7. Der Hash der entpackten Kernkomponente lautete b20f39fc00d242e706b6c30367ad811c676e0575050a4ec2f30104b696944b49. Angreifer nutzten die Tatsache aus, dass private Medienserver rund um die Uhr laufen, um unbemerkt Proxys zu betreiben und Kryptowährungen zu schürfen.
Bemerkenswert war auch die Methodik hinter der Entdeckung: Der Forscher nutzte einen KI-gestützten Workflow mit LLMs. Die Analyse gliederte sich in Aufklärung, Triage, Verifizierung und Verkettung, wobei spezialisierte Agenten jede Hypothese systematisch auf Falsifizierbarkeit prüften.
Menschliche Analysten behielten die strategische Kontrolle über Ausnutzung und Architektur, während KI-Tools den Aufwand für die Code-Analyse drastisch reduzierten. Die Hürde, mehrere kleinere Unachtsamkeiten zu einer verheerenden Kette zu verknüpfen, ist massiv gesunken. Schlecht abgesicherte Edge-Geräte in Privathaushalten stehen dabei an vorderster Front.
In dieser Kette gab es keine spektakulären Speicherüberläufe. Ein unvollständig geprüfter Header, ein verschluckter Rückgabewert im Decorator, ein nachlässiger Präfixvergleich und ein ungeprüfter Bibliotheks-Loader – isoliert betrachtet handelte es sich um typische Alltagsfehler.
Erst das fatale Design-Axiom von Plex, dass Verbindungen von localhost prinzipiell vertrauenswürdig seien, machte aus diesen kleinen Mängeln einen Generalschlüssel. Das Einspielen des bereitgestellten Sicherheitsupdates auf Version 1.43.3 oder neuer ist dringend geboten, um die eigenen Heimserver vor Krypto-Mining-Banden zu schützen.
Weiterführende Links:
- zmain.info: Sicherheitsbericht zu plex2shell
- BoredHackerBlog: Analyse der Angriffe in freier Wildbahn
- GitHub code-zm/plex2shell
- GitHub BoredHackerBlog/plex2shell_pcap
- Diskussion auf Hacker News (item?id=50152321)
