Seit Mitte Oktober warnt Plex vor breit angelegten Angriffen auf veraltete Medienserver, jetzt meldet auch ein NAS-Hersteller konkrete Fälle bei eigenen Kunden. QNAP hat am Freitag eine Sicherheitsmeldung zu „Plex2Shell“ veröffentlicht: Einige Nutzer hätten berichtet, dass Plex Media Server auf ihrem NAS offenbar über diese Lückenkette kompromittiert wurde, der technische Support kümmere sich um die Betroffenen. Laut QNAP-Sicherheitsteam (PSIRT) stecken die Schwachstellen nur in der Drittanbieter-App, QTS und QuTS hero sind nicht betroffen. Die Empfehlung fällt trotzdem deutlich aus: Wer Plex mit einer verwundbaren Version aus dem Internet erreichbar betrieben hat, soll das NAS als potenziell kompromittiert behandeln. Das Update schließt nur das Einfallstor – was Angreifer bereits installiert haben, bleibt.

Offen ist bislang, wie viele NAS-Systeme tatsächlich betroffen sind: QNAP nennt keine Zahl und spricht von Berichten einzelner Nutzer über mutmaßlich kompromittierte Systeme – bestätigte Einzelfälle führt der Hersteller nicht auf. Auch zu den Angreifern macht QNAP keine Angaben. Bekannt ist nur, wofür kompromittierte Plex-Server bislang missbraucht wurden: für Krypto-Miner und Proxy-Software.

Vier mittelschwere Fehler, eine kritische Kette

Plex2Shell besteht aus vier Schwachstellen in Plex Media Server vor Build 1.43.3.10861: CVE-2026-96652, CVE-2026-96654, CVE-2026-96655 und CVE-2026-96656. Einzeln sind sie wenig gefährlich. Die US-Cybersicherheitsbehörde CISA, die die CVE-Nummern vergeben hat, stuft drei davon als „mittel“ ein (CVSS 4.0: 5,3 bis 6,9) und nur eine als „hoch“ (8,6). Hintereinandergeschaltet erlauben sie laut Plex und QNAP aber einem nicht angemeldeten Angreifer aus der Ferne, Code mit den Rechten des Plex-Prozesses auszuführen. Der Entdecker Zach Main bewertet die gesamte Kette mit CVSS 9,8.

Seine Analyse zeigt, wie die Glieder ineinandergreifen. Der Endpunkt /player/timeline prüft nur, ob überhaupt ein X-Plex-Token mitgeschickt wird, nicht, ob es gültig ist. Über einen manipulierten Parameter bringt der Angreifer den Server dazu, eine Anfrage an sich selbst zu schicken, also scheinbar von 127.0.0.1. Solche lokalen Anfragen dürfen ohne Token auf die Plugin-Verwaltung zugreifen, wo eine wirkungslose Prüfung in der Funktion searchOne den Aufruf beliebiger Plugin-Funktionen erlaubt. Eine Funktion des mitgelieferten TheTVDB-Agenten lädt beliebige URLs, und das Plugin-Framework hängt dabei automatisch das Admin-Token des Server-Besitzers an, sobald die Adresse mit http://127.0.0.1 beginnt. Ein Hostname nach dem Muster 127.0.0.1.<IP>.sslip.io erfüllt diese Bedingung, zeigt aber auf den Rechner des Angreifers. Mit dem erbeuteten Token setzt er eine Transcoder-Option, die den Encoder x264 eine präparierte Bibliothek in den Codecs-Ordner schreiben lässt. Beim nächsten Transcodieren lädt Plex jede .so-Datei aus diesem Ordner, ohne Signaturprüfung.

Vom stillen Patch zur Angriffswelle

Behoben sind die Fehler schon länger. Main meldete sie am 27. Juli an Plex, der korrigierte Build 1.43.3.10861 erschien am 4. August für alle Nutzer. Am 1. September rief Plex alle Server-Betreiber zum Update auf, sprach aber nur allgemein von mehreren Sicherheitsproblemen. Die Shadowserver Foundation zählte daraufhin Anfang September mehr als 36.000 aus dem Internet erreichbare, ungepatchte Plex-Server. Die CVE-Einträge folgten am 23. September.

Am 16. Oktober veröffentlichte Main seine technische Analyse, laut Plex am selben Tag auch einen Proof of Concept. Schon am Morgen des 17. Oktober registrierte ein Honeypot des Betreibers von BoredHackerBlog die ersten echten Angriffe. Zuerst landete ein Krypto-Miner auf Basis von XMRig auf dem System, später am Tag eine Proxy-Software namens „myawesomeproxy“. Solche Programme leiten laut Plex fremden Datenverkehr über den Internetanschluss des Opfers. Plex bestätigte am 19. Oktober die breite Ausnutzung, einen Tag später nahm die CISA alle vier Lücken in ihren Katalog aktiv ausgenutzter Schwachstellen auf.

Vorsicht bei der Versionsnummer: Entscheidend ist der Build. Plex Media Server 1.43.3.10828 war schon seit Mitte Juli für alle verfügbar, ist aber noch verwundbar. Sicher ist erst 1.43.3.10861. QNAP rät, nach dem Update in Plex Web unter Einstellungen → Allgemein die vollständige Nummer zu kontrollieren.

Nicht nur QNAP betroffen

Weil die Fehler in Plex Media Server selbst stecken, spielt die Plattform keine Rolle. Plex richtet seine Warnung an alle Betreiber: Wer einen älteren Build als 1.43.3.10861 aus dem Internet erreichbar betreibt, soll von einer möglichen Kompromittierung ausgehen. Unter den Indizien nennt Plex fremde .so- und .dll-Dateien, also Bibliotheken für Linux und für Windows; Mains Exploit-Code lässt sich laut Projektbeschreibung auch für Windows-Ziele bauen. Eigene Warnungen von Synology, Unraid oder TrueNAS haben wir bis Freitagnachmittag nicht gefunden. Plex weist aber darauf hin, dass die Paketquellen der NAS-Hersteller neue Versionen nicht immer sofort anbieten, und empfiehlt dann, das passende Paket manuell von der Plex-Downloadseite zu installieren. Im QNAP App Center steht Build 1.43.3.10861 bereit, neuere Versionen will QNAP nach eigener Prüfung nachreichen. Bei Plex selbst ist seit dem 26. Oktober 1.43.5.11079 aktuell.

Bei Docker mit dem offiziellen Image plexinc/pms-docker enthalten das Tag „latest“ und die Versions-Tags den Server fest im Image; hier hilft nur ein neues Image. Die Tags „public“ und „beta“ laden die aktuelle Version dagegen bei jedem Neustart des Containers nach.

Was ein Angreifer nach einem Einbruch erreicht, hängt davon ab, worauf der Plex-Prozess zugreifen kann. Plex rät, alles als potenziell offengelegt zu betrachten, was das Dienstkonto erreicht: eingebundene Freigaben ebenso wie Zugangsdaten, die auf derselben Maschine oder VM liegen. Weil zudem das Admin-Token des Server-Besitzers abgeflossen sein kann, genügt ein neues Plex-Passwort allein nicht.

Symbolbild: Rückseite eines Heimrouters mit einem Internet-Anschluss und vier LAN-Ports

Bild: Ob Plex aus dem Internet erreichbar ist, entscheidet oft der Router – Portweiterleitungen und UPnP gehören auf den Prüfstand (Symbolbild: MikroTik hAP ac²). Foto: Smitop / Wikimedia Commons, CC BY-SA 4.0

Was du jetzt tun solltest

Prüfe zuerst die Version: in Plex Web unter Einstellungen → Allgemein, auf QNAP-Geräten zusätzlich im App Center bei den installierten Apps. Unter Linux und mit Docker geht es auch auf der Kommandozeile:

# Installierte Version (Debian/Ubuntu bzw. Fedora/RHEL)
dpkg-query -W -f '${Version}\n' plexmediaserver
rpm -q plexmediaserver

# Docker (Tag latest; feste Versions-Tags vorher anheben): Image holen, Container neu erstellen
docker compose pull && docker compose up -d

Danach kommt die entscheidende Frage: War Plex aus dem Internet erreichbar, solange eine alte Version lief? Das ist laut QNAP der Fall, wenn in Plex der Fernzugriff aktiv war, der Router Port 32400 weiterleitet, UPnP den Port automatisch geöffnet hat oder Plex über die automatische Router-Konfiguration von myQNAPcloud freigegeben war. Wenn ja, reicht das Update nicht. Plex und QNAP nennen diese Anzeichen für einen Einbruch:

  • unbekannte Prozesse, die Plex gestartet hat, besonders mit Namen wie myawesomeproxy, mylovelyminer oder x12345,
  • fremde .so- oder .dll-Dateien im Codecs-Ordner,
  • Verbindungen zu proxystream.st sowie dauerhaft hohe CPU-Last, obwohl nichts abgespielt wird,
  • auf QNAP-Geräten einen Fund des Malware Remover, etwa mit dem Code MR2104.

Auf Linux-Systemen hilft ein schneller Blick. Main stellt im GitHub-Repository des Exploits außerdem ein nur lesendes Prüfskript bereit, das auch Logs und Docker-Container durchsucht.

PMS="/var/lib/plexmediaserver/Library/Application Support/Plex Media Server"
# Docker: Pfad des /config-Volumes plus "/Library/Application Support/Plex Media Server"

# Prozesse mit den von Plex genannten Namen
ps aux | grep -E 'myawesomeproxy|mylovelyminer|x12345' | grep -v grep

# Transcoder-Option in den Einstellungen (dump-yuv ist ein Alarmzeichen)
grep -o 'TranscoderH264Options="[^"]*"' "$PMS/Preferences.xml"

# In den letzten 30 Tagen geänderte Bibliotheken im Codecs-Ordner
find "$PMS/Codecs" -type f -name '*.so' -mtime -30 -ls

Ein leerer Eintrag für TranscoderH264Options ist keine Entwarnung: Der öffentliche Exploit setzt die Option nach getaner Arbeit zurück. Findest du Spuren oder kannst du einen Einbruch nicht ausschließen, genügt es nicht, das verdächtige Programm zu löschen. QNAP empfiehlt eine saubere Neuinstallation von Plex. Sichere zuerst den Ordner „Logs“ (unter „Plex Media Server“ in der Freigabe PlexData), falls der QNAP-Support bei der Analyse helfen soll. Entferne dann die App. Einen verbliebenen Ordner „Plex Media Server“ solltest du nicht weiterverwenden – lösche mindestens den Inhalt des Codecs-Ordners und prüfe die Preferences.xml auf Transcoder-Optionen, die du nicht selbst gesetzt hast. Installiere anschließend 1.43.3.10861 oder neuer und spiele den alten Codecs-Ordner nicht zurück.

Danach sind die Zugangsdaten dran. Melde in den Einstellungen deines Plex-Kontos zuerst alle Geräte ab und ändere erst dann das Passwort. Auf dem NAS wechselst du die Passwörter von Admin und Nutzern, schaltest die Zwei-Faktor-Anmeldung ein und erneuerst gespeicherte Schlüssel anderer Dienste, etwa für Backup-Jobs und Cloud-Verbindungen.

Dauerhaft gilt: Brauchst du den Fernzugriff nicht, schalte ihn in Plex ab, lösche die Portweiterleitung für 32400 und deaktiviere UPnP im Router. Für unterwegs ist ein VPN die bessere Wahl, auf QNAP-Geräten zum Beispiel QVPN Service.

Quellen

Bildnachweis