Plex2Shell chain exploited against QNAP NAS devices running Plex Media Server

QNAP says it has received reports from some users that Plex Media Server on their NAS devices appears to have been compromised through a chain of four vulnerabilities, which SecurityWeek reports is being called Plex2Shell. The vendor's advisory went out on Friday; SecurityWeek published its write-up on 9 November 2026.

The chain was patched this summer. Widespread exploitation started in mid-October, according to SecurityWeek, after technical details and proof-of-concept code were published. That gap between patch and public exploit code is the part worth noting: the fix existed for months before the tooling did.

What happened

Plex Media Server ships as a third-party app for QNAP NAS through the official App Center, so a lot of these boxes sit on home and small-office networks with remote access turned on. QNAP's PSIRT says the flaws exist only in Plex Media Server, and that QTS, QuTS hero and other QNAP operating systems are not themselves affected. The QNAP support team is assisting affected users and says it has confirmed no data loss.

SecurityWeek reports that successful exploitation doesn't need valid credentials and can let an attacker run arbitrary code on exposed servers with the privileges of the Plex service.

How the chain works

Two of the four flaws are documented in CISA's known exploited vulnerabilities catalog, and both are in Plex Media Server before 1.43.3.10861.

The first is a server-side request forgery in the /player/timeline endpoint. An attacker using any X-Plex-Token value can put a full URL in the protocol parameter and make the Plex server POST to a destination of their choosing. On its own that's a medium-severity bug: the CVSS 3.1 base score is 4.3, with low confidentiality impact only. The interesting part is the "any X-Plex-Token value" wording. The token doesn't have to be valid, which lowers the bar considerably.

The second is improper neutralization of encoded URI schemes. The record says Plex doesn't correctly neutralize URL values in searchOne, letting an attacker call other plugins' functions and supply their own parameters. That one is rated 6.5 under CVSS 3.1 and 6.9 under CVSS 4.0, with no privileges required.

Neither record describes the full chain, and SecurityWeek doesn't walk through how the four combine into code execution. What's public is that they're designed to be used together, and that PoC code exists.

HackZoneLabs assessment

The severity scores here undersell the practical risk, in our view. A 4.3 SSRF and a 6.5 plugin-parameter bug look like housekeeping on a patch dashboard. Chained, with public exploit code and no credential requirement, they're a remote code execution path against a media server that many people exposed to the internet on purpose so they could watch films away from home. We'd rank this by exposure, not by CVSS.

The other thing we'd flag is the remediation advice. QNAP isn't telling people to patch and move on. It says devices reachable from the internet should be considered potentially compromised, that Plex should be reinstalled, and that both the Plex and NAS passwords should be rotated immediately. That's a vendor telling you its own patched app may already be dirty. Patching closes the door; it doesn't clear the room.

What's still unknown

Nobody has published how many devices were hit. QNAP says "some users" and stops there. SecurityWeek doesn't say who is doing the exploiting, what they do after they get in, or whether the activity is financially motivated. CISA's catalog entry lists ransomware use as unknown for both flaws, which is an absence of information rather than a clean bill.

The CISA entries also carry due dates under BOD 26-04: 23 October 2026 for the URI-scheme flaw and 3 November 2026 for the SSRF. Those dates have passed, which tells you the US federal clock on this ran out weeks ago.

What to check first

If you run Plex on a QNAP box, the version is the first question. QNAP advises updating to Plex Media Server 1.43.3 or later. The CISA records put the fixed build at 1.43.3.10861.

Then decide whether the box was ever reachable from outside. If it was, QNAP's position is that it should be treated as compromised: reinstall Plex, rotate the Plex and NAS passwords, and work through the vendor's remediation guide rather than assuming a version bump settled it. If you don't need remote access, turn off Plex Remote Access and stop forwarding port 32400. If you do need it, QNAP suggests a VPN instead. Keep QTS or QuTS hero and the installed apps current as well.

For anyone who can't establish whether the server was exposed, the honest answer is that the version number alone won't tell you. Look for signs of tampering on the host before you trust it again.

CVE references

CVE-2026-96652

CVE-2026-96654