QNAP NAS Devices Breached Through Plex2Shell (CVE-2026-96652, -96654, -96655, -96656): Patching Plex Won't Remove What Attackers Already Planted
QNAP says attackers are compromising NAS devices through the four-flaw Plex2Shell chain in Plex Media Server and warns that owners of internet-exposed servers should treat the device as compromised even after updating to 1.43.3.10861.
QNAP has warned owners of its network-attached storage (NAS) devices that attackers are breaking into them through Plex2Shell. Plex2Shell is a chain of four vulnerabilities in Plex Media Server, the popular media streaming app that many home users and small offices install from the QNAP App Center. The company says it has received multiple reports of suspected compromises. Its advice goes further than "update now": if your Plex server was exposed to the internet while vulnerable, assume the NAS and everything on it is compromised.
What Happened
The four flaws are tracked as CVE-2026-96652, CVE-2026-96654, CVE-2026-96655 and CVE-2026-96656. A security researcher reported them to Plex on 27 July 2026. Plex fixed them in Plex Media Server 1.43.3.10861, and full technical details were published on 16 October. Exploitation started soon after.
On 20 October, CISA added all four CVEs to its Known Exploited Vulnerabilities (KEV) catalog. Federal agencies were given just three days to upgrade, an unusually short deadline that shows how serious the agency considered the threat.
QNAP's advisory, published on 6 November, adds a new piece of information: the attacks have now reached QNAP NAS boxes running Plex. These devices often hold years of personal photos, documents and backups.
Technical Details
The researcher rates the full chain at CVSS 9.8: network-reachable, low complexity, and needing no credentials or user interaction. On its own, no single bug gives an attacker control. Together they lead from an anonymous request to code execution on the server. At a high level, the write-up describes these steps:
- Unauthenticated server-side request forgery (SSRF). A companion-protocol endpoint checked only that a token header was present, not that it was valid. That let an outsider make the server send requests to destinations the attacker chose, including its own loopback interface.
- Loopback trust bypass. An internal agent API trusted any request coming from localhost without a token. Broken input validation then let the attacker reach internal plugin functions.
- Owner token leak. An outbound-request helper attached the server owner's admin token to any URL that merely started with a loopback-style prefix. A lookalike hostname passed that check, so the token went to an attacker-controlled server.
- Configuration abuse to code execution. With the owner token, the attacker could change transcoder settings so that a file they supplied was written into the codec directory. The transcoder later loads that file as a shared library.
The end result is code execution as the Plex service user. On a NAS, that user can usually read the media and data shares Plex has been given access to.
Who Is Affected
- Anyone running Plex Media Server older than 1.43.3.10861 on any platform. QNAP NAS owners who installed it from the App Center are now confirmed targets.
- The highest risk falls on servers reachable from the internet, typically through Plex remote access or a forwarded TCP port 32400.
- QNAP stresses that QTS, QuTS hero and its other operating systems are not vulnerable. The flaws are entirely in Plex Media Server.
Patch Status
The fix is Plex Media Server 1.43.3.10861 or later, which is now the version offered in the QNAP App Center. QNAP warns clearly that updating does not remove anything an attacker has already installed. A server patched today after weeks of exposure may still be running someone else's payload.
What To Do Now
QNAP's guidance for NAS owners, in order:
- Update Plex Media Server to 1.43.3.10861 or later from the App Center.
- If your vulnerable Plex server was reachable from the internet, treat the NAS and all its content as compromised.
- Check for the signs of compromise listed in QNAP's security bulletin and remediation FAQ.
- If you find any, perform a clean reinstall of QTS or QuTS hero rather than trying to clean the system by hand.
- Reset both your Plex account credentials and your NAS administrator passwords, from a clean device.
- If you don't need remote streaming, disable Plex remote access and remove the router port-forward for 32400.
- If you do need it, reach the server through a VPN instead of exposing it directly.
- QNAP also invites users to send logs from suspected compromises to its technical support.
A quick way to see whether your server answers from outside your network is to check your router's port-forwarding table and Plex's own remote-access status page. Look for the version number under Settings → General in the Plex web app.
# On the NAS (SSH), list listening sockets for the Plex port
netstat -tlnp 2>/dev/null | grep 32400Why It Matters
Plex2Shell shows how home and small-office storage has become a real target. A NAS is "set and forget" hardware, and third-party apps on it are easy to overlook in patch routines. Many owners turned on remote streaming years ago and never thought about it again. Attackers count on exactly that.
There is also a lesson in the gap between patch and exploitation. The fix was available before the technical details went public. But the details came out on 16 October, KEV listing followed four days later, and now, three weeks after that, confirmed NAS compromises are still being reported. For internet-facing apps, "patched eventually" is not enough. And when a device has been exposed for that long, patching is only the first step of cleaning it up.
