Plex Media Server Update: Patch the Plex2Shell RCE Tonight — Self-Hosted Compromise Check (CVE-2026-96652)
Plex said it out loud this week: "These vulnerabilities are being actively and widely exploited." The exploit chain — Plex2Shell — has a public proof of concept and a payload your electricity bill will notice: compromised servers become crypto miners and someone else's proxy exit node, routing strangers' traffic through your home connection.
The twist that makes this a homelab story: the fix has existed since August 4. Plex shipped it quietly, urged everyone to update on September 1, and waited six weeks while most self-hosters never applied it. Then the PoC dropped October 16, exploitation was observed October 17, and CISA added all four CVEs to its Known Exploited Vulnerabilities catalog on October 20 — today is the remediation deadline for two of them. This is the operator's runbook: check exposure, patch every install type (including the NAS and Docker traps), and decide whether patching is enough or your server needs a clean rebuild.
What Plex2Shell actually is
Plex2Shell is four CVEs in Plex Media Server, published by Plex on October 19 after researcher zmain reported them on July 27 (Plex paid a $500 bounty August 4): CVE-2026-96652 (unauthenticated SSRF in the player timeline endpoint), CVE-2026-96654 (internal agent functions over loopback), CVE-2026-96655 (server owner's admin token disclosure), CVE-2026-96656 (arbitrary file write to the Codecs directory). Chained, Plex writes, "these issues let an unauthenticated remote attacker run code with the privileges of the Plex Media Server process." The researcher's tagline: "Unauth RCE chain for Plex Media Server ≤ 1.43.3.10828. Fixed in 1.43.3.10861. Update ASAP." Severity, attributed: researcher rates the chain CVSS 3.1 9.8; the CNAs scored individual CVEs 4.3–8.6.
The observed payloads: an XMRig crypto miner (mylovelyminer, x12345) plus residential-proxy software (myawesomeproxy) reselling your home connection as someone else's exit node. One correction before the rumor mill runs: CISA's KEV entry lists known ransomware use as "Unknown" — every verified report describes miners and proxyware, so don't repeat a ransomware claim nobody published.
Step 1 — The 60-second triage: are you exposed?
Two questions decide whether tonight is a patch job or a rebuild job. First, your version: open Plex Web → Settings → General and read it. Plex: "Plex Media Server 1.43.3.10861 and later are not affected." Anything older is vulnerable — and since the fixed build has been out since August 4, verify, don't assume. Second, your exposure: is Settings → Remote Access enabled and green? Is TCP 32400 forwarded to the Plex machine at your router?
ss -tunap | grep 32400 # 32400 listening AND forwarded at the router (or Remote Access on) # = internet-facing = the high-risk case.
Plex's rule, verbatim: "If your server is older than 1.43.3.10861 and reachable from the internet, assume it may be compromised." Internal-only on an old build still needs the update, but it isn't the house-on-fire case — exposed + unpatched since mid-October is.
Step 2 — Patch tonight: the exact target, every platform
Target: Plex Media Server 1.43.3.10861 or newer, plus Plex Desktop 1.115.0. Per Plex: Windows/macOS — confirm auto-update put you on 1.43.3+, otherwise install from Plex's downloads page. Linux — .deb via sudo dpkg -i (Ubuntu) or .rpm via sudo dnf install (Fedora/CentOS), substituting the real filename. NVIDIA Shield — Google Play, install pending updates. NAS and Docker — the traps; their own steps below.
Step 3 — The NAS trap: your app store is lying to you
Plex warns: on a NAS, "the updated version may not be available in their package manager yet but you can install the package manually." Synology, QNAP and the rest lag behind Plex's releases, and NAS boxes run unattended for months — which is why they're over-represented among victims. Download the package for your exact device and architecture from Plex's downloads page, open the NAS web interface, find the manual-install path (a dedicated button on some vendors, buried in Settings on others), and run the wizard. Then re-check Settings → General — the installed build is the only thing that counts. And if that NAS also holds your backups, read our SafePay NAS survival guide next: a compromised NAS-adjacent box is exactly when snapshot discipline pays off.
Step 4 — The Docker trap: don't trust the tag
Docker's version of the NAS lag: the tag says one thing, the running container another. Plex points Docker installs at the official pms-docker repo; community images rebuild on their own schedules. "Linux, NAS, and Docker installations need a manual update" — no auto-update saves you. The re-pull-and-verify loop (same discipline as our GitLab patch guide):
docker compose pull plex && docker compose up -d plex # Verify the RUNNING container, not the tag: # Plex Web → Settings → General must read 1.43.3.10861+.
Stale digest: pull says "up to date" but the version check shows an old build — your compose file pins a digest the maintainer hasn't rebuilt; check the image project's releases. The :latest gamble: pin the fixed build tag explicitly once published, and verify after every recreate. Watchtower users, remember the n8n 3.0 lesson: auto-update is convenience, not verification.
Step 5 — Can't patch tonight? Shrink the attack surface
If the NAS manual install waits for the weekend, take the target off the internet tonight. Plex: "If you don't need remote access, turn it off under Settings → Remote Access. Avoid forwarding port 32400 directly unless you need it." Disable Remote Access, kill the 32400 forward, and if remote streaming is non-negotiable, put Plex behind a VPN or authenticating reverse proxy — the attacker needs unauthenticated HTTP to 32400. A bridge, not a fix: patch the moment you can.
Step 6 — Hunt: check whether you're already compromised
ps aux | grep -Ei 'myawesomeproxy|mylovelyminer|x12345' | grep -v grep # Any hit = compromised. No hit does NOT mean clean.
Run these before deciding patching is enough — all indicators are Plex's own, from the October 19 update. 1. Hunt process names with the command above. 2. Inspect the Codecs folder for unfamiliar .so/.dll files — the chain's final stage writes a file the transcoder executes on load. 3. Watch the wire for outbound connections to proxystream.st in router/firewall logs. 4. Watch the CPU — Plex's tell is "sustained high CPU use while nothing is playing." 5. Check Preferences.xml for transcoder options you didn't set — attackers persist through configuration.
Step 7 — Patching closes the door; it doesn't evict the intruder
Plex's rule, verbatim: "If you find any of these, or you can't rule out compromise: rebuild the server from a clean installation rather than reusing the old Plex data directory." A patched-but-compromised server keeps mining for someone else. Rebuild when: the server was internet-facing and ran a build older than 1.43.3.10861 at any point since mid-October (especially October 16–17). Can't reconstruct the timeline? Err toward rebuild — the same assume-compromise call we made for Node2Shell.
Clean-rebuild sequence, per Plex: back up only verifiable media — never the Plex data directory, where persistence lives. Fresh install of 1.43.3.10861+. Delete everything in the Codecs folder, check Preferences.xml, sign out of all devices, change your Plex password, and treat anything the Plex service account could reach — mounted shares, credentials on the same machine or VM — as exposed. Rotate them.
Frequently asked questions
What is Plex2Shell?
Four CVEs (CVE-2026-96652, 96654, 96655, 96656) in Plex Media Server letting an unauthenticated remote attacker run code on the server. The PoC went public October 16, 2026; Plex confirmed October 19 the flaws are "being actively and widely exploited."
Which versions are affected?
All builds before 1.43.3.10861 — "1.43.3.10861 and later are not affected," per Plex. Check Plex Web → Settings → General. Plex Desktop needs 1.115.0+.
How do I know if my server was hacked?
Plex's signs: processes named myawesomeproxy, mylovelyminer or x12345; unknown .so/.dll files in the Codecs folder; outbound connections to proxystream.st; sustained high CPU with nothing playing. Internet-facing and unpatched since mid-October? Assume compromise.
I updated — am I safe now?
Only if it wasn't already compromised. Patching closes the hole; it doesn't remove an installed miner or proxy. If compromise is confirmed or can't be ruled out, Plex instructs a clean rebuild: fresh install, cleared Codecs, checked Preferences.xml, devices signed out, password changed.
My NAS app store lacks the update. What now?
Install manually — Plex warns the build "may not be available in their package manager yet." Download the package for your exact NAS model from Plex's downloads page and use the NAS manual-install path.
Should I disable Remote Access?
If you don't stream outside your LAN, yes — and remove the port-32400 forward. No WAN exposure means no unauthenticated internet attack path while you arrange the patch.
Comments
Post a Comment