Plex Media Server older than 1.43.3.10861 can be taken over remotely without a login by chaining four bugs called "Plex2Shell" (CVE-2026-96652, -96654, -96655, -96656). Exploit code went public on Oct 16, 2026, and a researcher's honeypot was hijacked on Oct 17 to run a Monero miner and a proxy. Fix: update Plex Media Server to the current release, 1.43.4.10903 (minimum 1.43.3.10861; 1.43.3.10828 is still vulnerable). Then turn off Remote Access if you don't need it, and check for miners and odd outbound traffic.

Status: exploited (researcher honeypot), fix available, last updated Oct 18, 2026, 2:05 PM ET. Primary sources: Plex security notice · CISA advisory VA-26-266-01 · NVD · researcher write-up · honeypot report

What to do now (home users)

1. Check your Plex Media Server version. Open Plex Web (app.plex.tv), go to Settings, pick your server under its name, then General: the version is shown at the top. You can also open http://<server-ip>:32400/identity on your home network and read the version= value. Anything below 1.43.3.10861 is vulnerable, and that includes 1.43.3.10828, so "1.43.3" alone is not enough. The current public release is 1.43.4.10903. Note that the Plex app on your TV, phone or streaming stick is not the server; the server is the computer, NAS or container that holds your media.
2. Update the server now. Windows/macOS: in Settings → General click Update (or Download from the Plex downloads page and install over the top). Ubuntu/Debian/Fedora: install the new .deb/.rpm from the downloads page (or sudo apt update && sudo apt install plexmediaserver if you added Plex's repository). NAS (Synology, QNAP, WD, TerraMaster, ASUSTOR, Netgear): the app store can lag, so download the package for your model from the downloads page and use the NAS's Manual Install; Plex links the vendor guides in its security notice. NVIDIA Shield: install pending updates in Google Play. Docker: see the next step.
3. If Plex runs in Docker or Unraid, update the container image. Pinned image tags never update themselves (the honeypot in this story ran linuxserver/plex:1.42.2). For plexinc/pms-docker: the public and beta tags install the newest build each time the container restarts (docker restart plex); a version tag or latest needs a new image: docker compose pull && docker compose up -d. For linuxserver/plex: with VERSION=docker (or unset) the version comes from the image, so pull a new image; VERSION=latest or public updates on restart. On Unraid, use Check for Updates on the Docker tab. Afterwards, confirm the version again in Settings → General.
4. Turn off Remote Access and port forwarding if you don't need them. The attack needs network access to port 32400. If you only watch at home, go to Settings → Remote Access and click Disable Remote Access, then remove any port forward for 32400 (or the manual port you set) on your router and turn off UPnP if nothing else needs it. If you do stream away from home, keep Remote Access on only after updating. Updating is still required: anyone on your home Wi-Fi, or a compromised device on it, can reach the server.
5. Look for a crypto miner (constant high CPU). A miner keeps the CPU near 100% even when nobody is watching, and fans run loud. Check Task Manager (Windows), Activity Monitor (macOS), the NAS Resource Monitor, or on Linux ps -u plex -o pid,ppid,%cpu,etime,cmd --sort=-%cpu and in Docker docker top plex. Anything running as the Plex user that is not Plex itself (Plex Media Server, Plex Transcoder, Plex Tuner Service, Plex Media Scanner, Plex Script Host, Plex Relay and similar) is suspicious, especially xmrig, files named x or docker in temp folders, or a shell (sh, bash).
6. Look for proxy or odd outbound traffic. The honeypot also got a residential-proxy tool ("myawesomeproxy") that rents out your internet connection to strangers. Signs: steady upload traffic when nobody is streaming, router or ISP warnings, or sites suddenly showing you CAPTCHAs. On Linux run sudo ss -tnp and look for connections owned by non-Plex processes; on Windows use Resource Monitor → Network. Your router's traffic page can show which device is uploading.
7. Rotate your Plex password and sign out every device. The exploit steals the server owner's admin token. At plex.tv, change your Plex account password (Account → Security) and tick the option to sign out connected devices, review Authorized Devices and remove ones you don't recognise, and turn on two-step verification. Sign your own apps back in afterwards.
8. If you find signs of compromise, rebuild. Disconnect the machine from the internet, then reinstall Plex Media Server at the current version (for Docker: delete and recreate the container from a fresh image). Remove unexpected files from Plex's Codecs folder (Plex re-downloads codecs) and check Preferences.xml for a TranscoderH264Options value containing dump-yuv. The attacker's code ran as the Plex user, so change passwords for anything that account could read (for example network shares or saved credentials on the same machine). If the server is a general-purpose PC, a full OS reinstall is the safest option.

What is confirmed

• The bugs and the fix. CVE-2026-96652 (SSRF via /player/timeline), CVE-2026-96654 (searchOne identifier injection), CVE-2026-96655 (transcoder SSRF via /video/:/transcode/universal) and CVE-2026-96656 (the TranscoderH264Options preference writes files that are loaded and run) were published Sep 23, 2026. NVD and CISA's advisory VA-26-266-01 say all are in Plex Media Server before 1.43.3.10861 and fixed in 1.43.3.10861. The same advisory lists a fifth bug fixed in that build, CVE-2026-96651: path traversal that can read the PlexOnlineToken (needs a valid token, or a LAN position).
• Fixed builds. Per Plex's release-notes thread, 1.43.3.10861 reached everyone on Aug 4, 2026, and the current public build 1.43.4.10903 on Sep 10, 2026. 1.43.3.10828 (Jul 14) is vulnerable.
• Plex's own notice. On Sep 1, 2026 Plex posted "Important Security Update for Plex Media Server v1.43.2 and earlier", telling owners to update to 1.43.3 or newer, with per-platform steps. It said CVE details would follow, but as of Oct 18, 2026, 2:05 PM ET the thread has no follow-up, and Plex has not commented publicly on the exploitation.
• How the chain works, per the researcher. ZM (@zm_0x) reported it to Plex on Jul 27; Plex acknowledged it and paid a bounty on Aug 4 ($500, per his post). His Oct 16 write-up shows how it works: a request with any junk X-Plex-Token makes the server call itself, a loopback-only plugin API is abused to send the owner's admin token to an attacker host, and then x264's dump-yuv option writes a shared library into the Codecs folder, which runs on the next transcode as the Plex user. The individual CVSS scores are moderate (NVD v3.1: 4.3, 6.5, 4.3, 7.2), but the chain needs no account. The researcher rates the chain 10.0.
• Exploit code is public. ZM posted the write-up and PoC link on Oct 16, 12:51 PM ET. A mirror of the code existed by 9:44 PM ET that day. The code-zm/plex2shell repo, as it now stands, was created Oct 18, 1:00 AM ET, and holds the Python exploit, Linux/Windows payloads, and (added Oct 18) a read-only hunt script and YARA rules. We read it but did not run it.
• Exploited in the wild (one honeypot). Researcher BoredHackerBlog reports that on the morning of Oct 17, 2026, a honeypot running a vulnerable Plex was hit using the published exploit code. It downloaded an XMRig Monero miner, and later a residential-proxy tool ("myawesomeproxy"). He published IPs, hashes and pcaps; see the hunt section below. This is one researcher's honeypot, not a measured campaign.
• Not on CISA KEV. None of the four CVEs is in CISA's KEV catalog (version 2026.10.16, checked Oct 18, 2026, 2:05 PM ET). An older Plex bug, CVE-2020-5741, has been on KEV since 2023; that is the one used against a LastPass engineer's home Plex in 2022.

Claims to treat carefully

• International Cyber Digest's post says the exploit was published "immediately after exploitation in the wild began". The sources show the reverse: the PoC came out Oct 16 and honeypot exploitation followed on Oct 17.
• The world map attached to that post appears to match Shadowserver's Sep 9, 2026 map: over 36,000 exposed servers on 1.43.2 or earlier, 16K of them in the US. That count is a month old, predates the PoC, and may not include servers on the still-vulnerable 1.43.3.10828. No current count for this chain has been published.
• Posts saying "fixed in 1.43.3" are imprecise: you need 1.43.3.10861 or later. The PoC README's line "< 1.43.3.10828" conflicts with NVD and CISA; go by "before 1.43.3.10861".
• Single user reports on X describe automated attacks on home servers. One says an attack failed because the payload expected a non-Docker install. These are unverified.

Unknown so far

• How many real servers have been compromised. No vendor, GreyNoise or Shadowserver exploitation data has been published for this chain as of Oct 18, 2026, 2:05 PM ET.
• Whether attackers are doing more than mining and proxying (for example stealing Plex account tokens or moving into home networks).
• Whether Plex will notify owners of still-vulnerable servers, or whether CISA will add the CVEs to KEV.

For defenders

• Exposure: find PMS on TCP 32400 (including staff home labs that reach corporate SSO or VPN; the LastPass precedent). Shadowserver tags vulnerable servers vulnerable-plex in its free Vulnerable HTTP reports for network owners. Patch to 1.43.3.10861 or later, ideally 1.43.4.10903.
• IOCs, detections and hunt steps: see Hunt: Plex2Shell exploitation.
• Home-user guide to share: Running Plex at home: the safety basics.