Plex2Shell Was Exploited Within a Day of the Exploit Going Public. The Patch Had Been Out for Six Weeks.
If you run Plex Media Server and it is older than 1.43.3.10861, update it today. If it was reachable from the internet before you did, Plex says to assume it may be compromised. A four-bug chain called Plex2Shell gives an attacker with no account code execution on the server. The exploit code went public on October 16. A honeypot saw it used against a real Plex server the next morning. The fix had shipped on September 1.
What happened
The researcher who goes by zmain found the chain, reported it to Plex on July 27, and was paid a bounty on August 4. Plex released Plex Media Server 1.43.3 on September 1 with a short advisory that gave no details. Four CVEs were assigned on September 23: CVE-2026-96652, CVE-2026-96654, CVE-2026-96655 and CVE-2026-96656. The full write-up and working code went up on October 16.
BoredHackerBlog had been running a vulnerable Plex honeypot since the advisory, waiting. On the morning of October 17 it saw the first real exploitation. The attacker was running the public exploit almost unchanged: the request carried a client name starting with "poc_", a Python-urllib user agent, and the same callback port, 8952, used in the write-up's example. Three source IPs did the exploiting: 45.194.92[.]222, 91.92.40[.]202 and 176.65.139[.]228.
On October 19 Plex updated its advisory. It now says the bugs are being "actively and widely exploited" against servers that were not updated.
How the chain works
Each bug alone is modest. Together they walk from the internet to a shell.
A remote-control endpoint, /player/timeline, only checks that a token header exists, not that it is valid. Its callback URL can be pointed anywhere, including back at the server itself on 127.0.0.1. That is CVE-2026-96652.
Plex trusts requests from 127.0.0.1 without a token. A broken check in the plugin search lets the attacker steer that local request to any plugin function. That is CVE-2026-96654.
The chosen function fetches a URL. Plex attaches the owner's admin token to any outbound request whose URL begins with "http://127.0.0.1". The check only looks at the first characters, so a hostname like 127.0.0[.]1.45-194-92-222.sslip[.]io passes. That is CVE-2026-96655.
With the owner token, the attacker sets a hidden encoder option that makes the video encoder dump its output to a file path the attacker picks, then feeds it a video whose pixels are, byte for byte, a Linux shared library. The file lands in the Codecs folder. On the next transcode Plex loads every library in that folder, unsigned, and the attacker's code runs. That is CVE-2026-96656.
The sslip trick, in plain terms
sslip[.]io is a free, legitimate DNS service. Any name that embeds an IP address resolves to that IP. So 127.0.0[.]1.45-194-92-222.sslip[.]io resolves to 45.194.92[.]222, the attacker's own machine. To Plex the name looks local. To the network it goes straight out. The server sends its owner token to the attacker.
That gives you a cheap detection. A media server has no reason to look up a sslip[.]io name that starts with 127.0.0.1. If your router, Pi-hole or firewall logs DNS, search for it. We would alert on it rather than block all of sslip[.]io, because other people use the service for honest work.
What the attackers did after getting in
The first payloads were a cryptominer. A file called "docker" and a packed binary called "x" came from 217.60.194[.]116, and an xmrig miner followed. Then came proxyware called "myawesomeproxy". It prints a line saying that running it means you "agree to the potential external use of your internet traffic." It talks to proxystream[.]st. The honeypot author points to a Bitsight write-up on the Aisuru botnet that mentions the same service; we have not verified that link ourselves.
Proxyware is the part to take seriously. A home Plex server sits on a residential IP. Someone else's traffic going out through your connection looks like you to the sites on the other end. The honeypot's author called this out before the proxy showed up. Plex lists these process names to look for: myawesomeproxy, mylovelyminer and x12345.
What our feed held, and who held it first
Short answer: our feed carried other people's early records, and our own sensors saw nothing of this attack.
What we ingested: on October 19 we added 7 indicators from the honeypot report: the four IPs and three hashes, at confidence 70 to 75. On October 20 we added two more hashes from the same report, the xmrig miner and the unpacked "x" binary, at 85. Each one was read back after the write. That is an ingest of someone else's research. It is not a detection.
What was already there, from other people:
Spamhaus DROP has listed 176.65.139[.]0/24 since at least February 8 and 45.194.92[.]0/24 since at least February 12, at confidence 95. It also lists 91.92.40[.]0/24 today, but our index does not keep the date it first appeared. A subscriber blocking on our ips.csv at confidence 80 was blocking those three ranges before the exploit existed. That is block coverage of the range, not knowledge of the attacker. The credit is Spamhaus's.
176.65.139[.]228 was listed by URLhaus on August 11 serving Mirai binaries on port 6677, and by ThreatFox submitters on August 16 as a C2 on ports 6677 and 6678. That is reused bad infrastructure, not foresight about Plex.
The unpacked "x" binary was posted by Nextron Research on August 5, and ThreatFox labeled it Mirai on October 3. The payload is older than the exploit.
The payload server's URLs, the xmrig hash and ota.proxystream[.]st came in from ThreatFox this morning, October 20. That is after the report.
What our own sensors saw: our edge canaries trapped 26 probes from other hosts in 176.65.139[.]0/24 between May 3 and June 29, and 3 from a host in 91.92.40[.]0/24 in August and September. All of them were hunting for .env files on our web sites. None came from the exact attacker IPs, and none touched Plex. A neighbor in the same /24 tells you the range is dirty. It does not mean we saw this attacker. We checked all four attacker IPs against our edge blocks, canaries and origin honeypot back to May 1: zero hits. We also have no Plex trap at all, so our edge could not have seen this attack. That is a coverage gap, not a quiet week.
One more honest note. The report IPs went in at 70 and 75, below the 80 floor our own edge blocks at. They are in the default ips.csv, but a subscriber pulling at 80 gets the three DROP ranges and not 217.60.194[.]116.
What to do if you run Plex at home or in a small office
Update to 1.43.3.10861 or newer. Check in Plex Web under Settings, then General. If your NAS app store lags behind, install the package from Plex's downloads page by hand.
If you don't need streaming from outside your house, turn off Remote Access. Don't forward port 32400 on your router unless you need it.
If you need remote access, put Plex behind a VPN such as WireGuard or Tailscale instead of opening it to the whole internet.
Look for signs of compromise: processes you don't recognize under the Plex account, .so or .dll files in the Codecs folder that you didn't put there, high CPU while nothing is playing, and connections to proxystream[.]st.
If you find anything, or can't rule it out, rebuild from a clean install. Don't reuse the old Plex data folder. Sign out all devices and change your Plex password. Assume anything the Plex account could reach was exposed, including mounted shares.
Run Plex as its own unprivileged user, not as root or as your own account, and give it read-only access to your media where you can. That limits what a stolen server can touch.
Credit
The research is zmain's. The first in-the-wild sighting and the indicators are BoredHackerBlog's, who also published packet captures for anyone writing detections. The early records belong to Spamhaus, URLhaus, ThreatFox submitters and Nextron Research. Plex fixed the bugs six weeks before anyone could weaponize them in public. The 45 days between fix and exploit were the window, and for the servers that stayed old, one day was enough.
Primary sources: https://www.boredhackerblog.info/2026/10/plex-vulnerabilities-being-exploited-in.html and https://zmain.info/blog/plex2shell and https://forums.plex.tv/t/important-security-update-for-plex-media-server-v1-43-2-and-earlier/942319
The free key that pulls our feed, at any confidence threshold you choose, is at https://analytics.dugganusa.com/stix/register?utm_source=blog&utm_campaign=plex2shell
If this was useful, or if it wasn't, the rating widget below takes ten seconds and is the only way we know.
Every indicator in this post is in the feed. Free.
1.58M+ IOCs, STIX 2.1 / TAXII, 88% novel vs ThreatFox, exploited-CVE leads ahead of CISA. No credit card — a free API key in 30 seconds, and you can audit every claim above against the live endpoints.
Was this useful? Thirty seconds, no cookies, no tracking, no third parties, your address hashed and never stored. If the box below does not load, the same question lives at https://analytics.dugganusa.com/nps.html?post=plex2shell-was-exploited-within-a-day-of-the-exploit-going-public-the-patch-had-been-out-for-six-we
Comments