QNAP is warning customers that attackers are compromising Plex Media Server installations on its NAS devices through Plex2Shell, a chain of four Plex vulnerabilities that lets an unauthenticated remote attacker run code on an unpatched server. Plex says the flaws are being “actively and widely exploited,” and the U.S. Cybersecurity and Infrastructure Security Agency (CISA) has listed all four in its Known Exploited Vulnerabilities catalog.
In a security notice dated November 6, 2026, QNAP said it has received reports from some users that Plex Media Server on their NAS “appears to have been compromised” through these vulnerabilities. Its technical support team is helping affected users and has confirmed that no data loss has occurred. QNAP did not say how many devices were hit.
Four flaws chained into remote code execution
Plex2Shell is tracked as CVE-2026-96652, CVE-2026-96654, CVE-2026-96655 and CVE-2026-96656. In its security announcement, Plex describes them as an unauthenticated server-side request forgery (SSRF) in the player timeline endpoint, access to internal agent functions over the loopback interface, disclosure of the server owner’s admin token, and an arbitrary file write to the Codecs directory through transcoder preferences. Chained together, they let an attacker run code with the privileges of the Plex Media Server process.
The researcher who found the chain, who publishes as ZM, released a technical write-up and a proof-of-concept exploit on October 16. The write-up rates the chain 9.8 on CVSS 3.1. The attacker:
- Sends a request with a junk token, since the endpoint only checks that a token exists, not that it is valid.
- Tricks the server into calling itself from 127.0.0.1, where its plugin API trusts requests without a token.
- Abuses a prefix check so the server attaches the owner’s admin token to a request that actually goes to the attacker.
- Uses that token to make the transcoder write an attacker-built shared library into the Codecs folder, which Plex loads and runs on the next transcode.
According to the write-up, ZM reported the bugs to Plex on July 27, 2026. Plex acknowledged the report and paid a bounty on August 4, and CVEs were assigned on September 23.
Exploitation began within a day of the public exploit
Plex shipped the fix in version 1.43.3 and urged owners to update on September 1, before CVE details were public. On October 19, Plex updated its post to say it had seen widespread attacks against internet-facing servers that had not been updated since the proof of concept was released. Compromised servers have been used to run cryptocurrency miners and proxy software that routes other people’s traffic through the victim’s internet connection.
One independent researcher who ran a vulnerable Plex honeypot reported the first in-the-wild exploitation on the morning of October 17, the day after disclosure. The attacks came from three IP addresses and dropped an XMRig cryptocurrency miner, followed later that day by a residential proxy tool named “myawesomeproxy.” Packet captures and samples are public for defenders.
CISA added all four CVEs to its Known Exploited Vulnerabilities catalog on October 20. Federal civilian agencies had until October 23 to fix CVE-2026-96654 and CVE-2026-96656, and until November 3 for the other two. CISA also flagged CVE-2026-96656 for forensic triage, meaning agencies are expected to look for signs of compromise, not just patch.
Why NAS owners are exposed
Plex on a NAS often sits on a home or small office connection with Remote Access on, which is valuable to proxy operators who sell residential IP addresses. QNAP’s security team said the vulnerabilities exist only in Plex Media Server and that QTS, QuTS hero and other QNAP operating systems are not affected. The fixed Plex release, 1.43.3.10861, is available in the QNAP App Center.
BreachNews recently covered C3RB3R ransomware attacks on outdated Synology NAS devices and the earlier PHP2Shell vulnerabilities. Hijacked consumer devices also feed residential proxy networks, as in the XCPE botnet hidden in Android TV boxes.
What Plex and QNAP users should do
Both companies say updating alone is not enough if a vulnerable server was reachable from the internet:
- Update now. Confirm in Plex Web under Settings, then General, that the version is 1.43.3.10861 or later. Check the full build number, since the exploit’s notes list early 1.43.3 builds up to 1.43.3.10828 as vulnerable.
- Assume compromise if exposed. If Plex 1.43.2 or earlier was reachable through Remote Access, a forwarded port 32400 or UPnP, treat the device as potentially compromised.
- Look for indicators. Plex lists unknown processes started by Plex Media Server (such as myawesomeproxy, mylovelyminer or x12345), unfamiliar .so or .dll files in the Codecs folder, connections to proxystream.st, transcoder options in Preferences.xml you did not set, and high CPU use while nothing is playing.
- Rebuild, do not reuse. Reinstall Plex cleanly instead of reusing the old data directory, and at minimum empty the Codecs folder. QNAP says to preserve the Plex Logs folder first if you want its support team to confirm a compromise.
- Reset credentials. Sign out of all devices in your Plex account, change your Plex password and reset NAS credentials. Treat mounted shares and credentials on the same machine as exposed.
- Cut exposure. Turn off Plex Remote Access if you do not need it, stop forwarding port 32400, and use a VPN for remote viewing.
QNAP has also published a step-by-step check and remediation FAQ for NAS owners and says it will update its notice as Plex shares more.
