NAS unter Beschuss: QNAP warnt vor Plex2Shell-Angriffen auf Plex-Server

QNAP meldet am 6. November 2026 Angriffe auf NAS-Geräte, bei denen Kriminelle den Plex Media Server über die Plex2Shell-Lücken übernehmen. Betroffen sind laut der QNAP-Sicherheitsmitteilung Plex-Versionen bis 1.43.2, die aus dem Internet erreichbar waren. Die Betriebssysteme QTS und QuTS hero sind nach Angaben des Herstellers nicht verwundbar. Ein Update entfernt bereits installierte Schadsoftware jedoch nicht.

Was QNAP auf betroffenen NAS-Geräten beobachtet

QNAP bestätigt in seiner Mitteilung vom 6. November 2026, dass Nutzende kompromittierte Plex-Server auf ihrem NAS gemeldet haben. Der technische Support des Herstellers betreut die Fälle. Plex selbst hält die Angriffe laut QNAP für aktiv und weit verbreitet. Die Zahl der betroffenen Geräte nennt QNAP nicht.

Ein NAS ist ein Netzwerkspeicher, auf dem viele Menschen Backups und Mediensammlungen ablegen. Plex Media Server läuft dort als Zusatz aus dem QNAP App Center. Er streamt Filme, Serien und Musik direkt von den Laufwerken. Wer unterwegs zugreifen will, öffnet häufig Port 32400 zum Internet. Genau dort klopfen die Angreifenden an.

Die Vorgeschichte ist kurz. Der Sicherheitsforscher Zach Main meldete die Fehler laut BleepingComputer am 27. Juli 2026 an Plex. Seine technischen Details erschienen am 16. Oktober 2026. Schon am 17. Oktober tauchten laut BleepingComputer erste Berichte über Angriffe auf. Sie trafen zunächst Köderserver, sogenannte Honeypots, auf denen ein Kryptominer landete.

Am 20. Oktober 2026 nahm die US-Behörde CISA alle vier Lücken in ihren Katalog ausgenutzter Schwachstellen (KEV) auf. Bundesbehörden sollten laut BleepingComputer innerhalb von drei Tagen auf Plex 1.43.3.10861 oder neuer wechseln. Wie das Magazin schon berichtet hat, geht es um aktiv ausgenutzte Plex-Server vor Version 1.43.3.10861. Ein Patch vor dem Angriff ist im KEV-Katalog keine Ausnahme, wie die Magento-Lücke mit Patch seit Juli und die Inventar-Frage hinter fünf alten Lücken zeigen. Ein Patch, den niemand einspielt, ist bloß eine Datei.

Was auf den Geräten landet, beschreibt The Hacker News am 19. Oktober 2026. Die Angreifenden laden per wget oder curl einen Kryptominer nach. Zusätzlich installieren sie laut VirusTotal eine Linux-Hintertür, die als Reverse Proxy arbeitet. Ein Reverse Proxy schleust fremden Internetverkehr durch das infizierte Gerät. Dazu kommt ein Miner der Software XMRig. Ihr NAS rechnet dann für Fremde und tarnt deren Datenverkehr. Den Strom bezahlen Sie.

Eine Subdomain der vom Miner genutzten Domain brachte Bitsight im August 2026 mit dem Botnetz AISURU in Verbindung. Auf Reddit berichten mehrere Nutzende von Instanzen mit demselben Miner. Ob dahinter Plex2Shell steckt, ist laut The Hacker News offen.

Wie aus vier Fehlern eine Shell wird

Plex2Shell verkettet vier Schwachstellen im Plex Media Server zu einem Angriff, den Zach Main mit dem CVSS-Wert 9,8 als kritisch einstuft. CVSS ist das gängige Maß für den Schweregrad einer Lücke. Die Einzelfehler gelten laut BleepingComputer vom 21. Oktober 2026 als mittel bis hoch. Erst die Kette öffnet ohne Anmeldung eine Shell, also eine Kommandozeile auf dem Gerät.

Dieses Bild wurde mit KI generiertProviderhiggsfieldModellgpt_image_2_5 flare high 1k 16:9Promptflat vector illustration, horizontal schematic of an attack chain seen from straight above, four connected chain-link blocks in teal, blue, orange and red, linked by arrows from left to right, each block with a simple abstract icon (a request arrow looping back, a link with a broken piece, a gear, a file page), ending at a terminal window with a blinking cursor beside a small NAS icon, clean geometric shapes, light cream background, bold outlines, no numbers, no labels with digits, no people, no hands. No watermark, no signature.

Die Tabelle zeigt die vier Schwachstellen mit Fehlerart, Fundstelle und nötiger Berechtigung nach der Beschreibung von BleepingComputer. SSRF steht dabei für Server-Side Request Forgery, also Anfragen, die der Server im Auftrag der Angreifenden stellt.

Der erste Schritt braucht kein Passwort. Der Endpunkt /player/timeline prüft laut Mains Beitrag vom 16. Oktober 2026 nur, ob der Header X-Plex-Token existiert. Ob der Wert stimmt, prüft er nicht. Ein beliebiger Text genügt. Der Parameter protocol landet zudem ungeprüft in einer Adresse. So schickt der Server eine Anfrage an sich selbst, über die Loopback-Adresse 127.0.0.1. Unter ihr erreicht ein Rechner nur sich selbst. Anfragen von dort gelten als vertrauenswürdig.

Auf dem Loopback-Weg wartet die Plugin-Schnittstelle /system/agents, die dort ohne Token antwortet. Eine Schutzabfrage in searchOne läuft ins Leere, weil der umhüllende Lock-Wrapper ihren frühen Abbruch verschluckt. Zeichen wie ? und # in der Kennung steuern dann Pfad und Parameter der nächsten Anfrage. Damit lässt sich jede Plugin-Funktion aufrufen. Die Anfrage ist blind, Antworten sehen die Angreifenden nicht. Das reicht ihnen.

Dann folgt der Griff nach dem Schlüssel. Das Plugin-System hängt laut Main an jede ausgehende Anfrage, deren Adresse mit http://127.0.0.1 beginnt, das Admin-Token des Servers, also den digitalen Generalschlüssel. Geprüft wird nur der Anfang der Zeichenkette. Eine Adresse wie 127.0.0.1.angreifer.sslip.io besteht den Test. Per DNS führt sie trotzdem zum Rechner der Angreifenden. Der Server liefert den Generalschlüssel selbst aus.

Brisant wird die Nutzlast. Mit dem Token setzen die Angreifenden die Einstellung TranscoderH264Options auf die Debug-Option dump-yuv des mitgelieferten Video-Encoders x264. Der Encoder schreibt damit Bilddaten an einen frei gewählten Pfad. Sie reichen ein präpariertes Video ein, dessen Bilddaten eine ausführbare Linux-Bibliothek darstellen. Verlustfrei kodiert, kommt sie bitgenau im Codecs-Verzeichnis an.

Beim nächsten Transcoding, dem Umwandeln von Videoformaten, lädt Plex jede .so-Datei in diesem Ordner. Es prüft laut Main weder eine Signatur noch ein bestimmtes Namensmuster. Der Startcode der Bibliothek läuft dann unter dem Benutzerkonto plex. Der Medienserver streamt eben alles, auch Schadcode.

Laut SonicWall vom 29. Oktober 2026 ist die Erreichbarkeit des Servers aus dem Internet die zentrale Voraussetzung für einen erfolgreichen Angriff. Plex lieferte den Patch Anfang August 2026, lange vor der Veröffentlichung der Details. Zeit zum Aktualisieren gab es reichlich.

Warum ein Update das kompromittierte NAS nicht rettet

Ein Update von Plex Media Server auf 1.43.3.10861 schließt die Lücken, entfernt laut QNAP aber keine Schadsoftware, die bereits auf dem NAS liegt. Dass QTS unberührt bleibt, tröstet wenig. QNAP rät, das NAS samt allen persönlichen Inhalten als kompromittiert zu behandeln, wenn ein verwundbarer Plex-Server aus dem Internet erreichbar war. Als Wege nennt der Hersteller aktiviertes Plex Remote Access, eine Weiterleitung von Port 32400 oder automatisch geöffnete Ports per UPnP. UPnP ist ein Protokoll, mit dem Geräte selbst Ports am Router freischalten. Ihr NAS kann also offen sein, ohne dass Sie je etwas geöffnet haben.

Die Tabelle zeigt Spuren einer Infektion, die SonicWall am 29. Oktober 2026 auflistet.

Wer eine davon findet, sollte den Rest nicht mehr für Zufall halten. Bei Verdacht empfiehlt QNAP, die Anzeichen aus der eigenen Meldung zu prüfen, das Betriebssystem QTS oder QuTS hero sauber neu zu installieren und danach die Zugangsdaten für Plex und NAS zurückzusetzen. Dafür hat der Hersteller eine Schritt-für-Schritt-Anleitung veröffentlicht. Auf Wunsch untersucht der Support auch Protokolle verdächtiger Geräte.

Wer Plex außerhalb eines NAS betreibt, findet bei SonicWall weitere Maßnahmen. Ein vorgeschalteter Reverse Proxy kann den Parameter protocol auf /player/timeline prüfen oder entfernen. Dazu kommen IPS-Signaturen, also Erkennungsmuster eines Intrusion-Prevention-Systems, am Netzwerkrand.

So gehen Sie nach QNAPs Empfehlung vor:

1. Öffnen Sie im App Center den Bereich My Apps und aktualisieren Sie Plex Media Server auf 1.43.3 oder neuer.
2. Bestätigen Sie in Plex Web unter Settings → General, dass die Version 1.43.3.10861 oder höher lautet.
3. Deaktivieren Sie Plex Remote Access und leiten Sie Port 32400 nicht weiter, wenn Sie den Fernzugriff nicht brauchen.
4. Richten Sie für den Fernzugriff ein VPN ein, falls Sie ihn benötigen.
5. Aktualisieren Sie QTS oder QuTS hero und alle installierten Apps.
6. Sichern Sie bei Verdacht den Plex-Logs-Ordner, bevor Sie Plex Media Server entfernen, und öffnen Sie einen Fall beim QNAP-Support.

Tipp: Prüfen Sie in Ihrem Router, ob UPnP den Port 32400 selbstständig geöffnet hat, denn QNAP nennt diesen Weg ausdrücklich.

Spätere Plex-Versionen will QNAP erst nach Prüfung bereitstellen, ein Datum nennt der Hersteller nicht. Warten sollten Sie darauf nicht. Das Update auf 1.43.3.10861 gehört noch heute auf Ihr NAS. Offen bleibt, wie viele Geräte betroffen sind: QNAP will seine Mitteilung ergänzen, sobald neue Informationen vorliegen.