BREAKING: Plex Media Server hijacked without a login to mine crypto and run proxies, now on CISA KEV (Plex2Shell, CVE-2026-96652)

Attackers are taking over Plex Media Server installs that missed the September update, with no Plex login, then using them to mine cryptocurrency and to route other people's traffic through the owner's home internet connection. The entry point is CVE-2026-96652, the first of four bugs that a researcher chained into a public exploit called Plex2Shell on October 16. Exploitation showed up on a honeypot the next day. Plex confirmed "actively and widely exploited" attacks on October 19, and today, October 20, CISA added all four CVEs to its Known Exploited Vulnerabilities catalog. If your Plex server is older than 1.43.3.10861 and reachable from the internet, update it now, then read the compromise checks below. Plex's own words: assume it may be compromised.

This is our operator read of Plex's security update thread, the researcher's Plex2Shell write-up, the honeypot report that caught the first attacks, and the CISA KEV entries. The source record lives in the HOL Guard evidence pack.

How to fix

Update to Plex Media Server 1.43.3.10861 or newer. Plex says that build and everything after it is not affected. To see what you run, open Plex Web and go to Settings → General; the version is on that page.

If you can't update right now, Plex's advice is to turn off Settings → Remote Access if you don't need it, and to stop forwarding port 32400 straight to the server.

Why a "medium" SSRF ended up on the KEV list

Taken one at a time, these bugs looked minor. Three of the four carried medium CVSS scores when the CVEs were published in September, and the worst one requires an admin. That is probably why plenty of servers sat on 1.43.2 for six weeks. Chained, they go from no account to running code on the box. The researcher's write-up walks through it, and each step is a small mistake:

1. CVE-2026-96652, the way in. The /player/timeline companion endpoint checks that an X-Plex-Token header exists, not that it is valid. X-Plex-Token: junk passes. A protocol parameter that ends up in a callback URL lets the attacker make the server send a POST to itself on 127.0.0.1.
2. CVE-2026-96654. Requests from 127.0.0.1 reach the plugin agent API under /system/agents/ with no token at all. Its searchOne check for a known agent never actually stops anything, and the identifier goes into an internal URL unencoded, so the attacker can call any plugin function with their own parameters.
3. Token theft. The bundled TheTVDB agent has a function that fetches a URL. The plugin framework attaches the server owner's admin token to any URL that starts with http://127.0.0.1, and a hostname like 127.0.0.1.<attacker-ip>.sslip.io starts with that string while resolving to the attacker. The owner token gets sent to them.
4. CVE-2026-96655 and CVE-2026-96656. With the owner token, the attacker points the transcoder at a video they host and sets the TranscoderH264Options preference so x264's dump-yuv option writes the decoded frames to a .so file in the Codecs folder. The frames are a byte-exact shared library. On the next transcode, Plex loads every .so in that folder with no signature check, and the attacker's code runs.

The code runs as whatever account the Plex service runs as. In the researcher's proof of concept that was uid=1000(plex). Anything that account can read is in reach: your media shares, mounted drives, and other credentials on the same machine or VM.

What attackers are installing

The honeypot operator saw the first exploitation on the morning of October 17, using the public exploit code, possibly modified. The request in their logs is easy to recognize: a hit on /player/timeline/subscribe whose protocol value points at http://127.0.0.1:32400/system/agents/.../searchOne with an sslip.io callback host, sent with a Python-urllib/3.10 user agent. The payloads were an XMRig-based Monero miner and a program called myawesomeproxy, which prints a notice that running it means agreeing to "potential external use of your internet traffic."

The miner costs you electricity. The proxy is worse. Plex servers mostly sit on home connections, and a residential IP is what someone wants when they log into other people's VPNs and email accounts. The honeypot operator made the same point. Your IP address becomes the source of somebody else's break-in.

Check whether your server was hit

Updating closes the hole. It does not remove a miner or proxy that is already running, or undo a preference the attacker set. Plex lists these signs:

• Processes started by Plex Media Server that you don't recognize, especially myawesomeproxy, mylovelyminer or x12345.
• Unfamiliar .so (Linux) or .dll (Windows) files in the Plex Codecs folder.
• Outbound connections to proxystream.st, or sustained high CPU while nothing is playing.

On a Linux package install, three quick checks:

# Anything Plex spawned that isn't Plex
ps -u plex -o pid,etime,args | grep -viE 'Plex (Media Server|Tuner|Script|Transcoder|Relay|DLNA|Plug-in)|Plex Media Scanner|Plex Commercial'

# Transcoder options you never set (the exploit uses dump-yuv)
grep -o 'TranscoderH264Options="[^"]*"' "/var/lib/plexmediaserver/Library/Application Support/Plex Media Server/Preferences.xml"

# Shared libraries in the Codecs folder, newest first
find "/var/lib/plexmediaserver/Library/Application Support/Plex Media Server/Codecs" -name '*.so' -printf '%TY-%Tm-%Td %TH:%TM  %p\n' | sort -r | head -20

Docker and NAS installs keep the same Preferences.xml and Codecs folder inside the Plex data directory, wherever you mapped it. Any dump-yuv value in TranscoderH264Options is a strong sign the exploit ran. A .so with a timestamp after October 16 that you can't tie to a Plex update deserves a hard look.

If you run Plex behind a reverse proxy, search its access log for the entry request:

grep -E '/player/timeline/subscribe.*protocol=http' /var/log/your-proxy/access*.log

The honeypot logged exploitation from 45.194.92.222, 91.92.40.202 and 176.65.139.228, with payloads served from 217.60.194.116. Those come from one honeypot over a short window, so a clean result on them proves little. The researcher published detection rules in the plex2shell repo, and the honeypot operator posted packet captures for signature work.

If you find something, or can't rule it out

Plex's guidance, in order:

1. Rebuild the server from a clean installation instead of reusing the old Plex data directory. At minimum, delete everything in the Codecs folder and remove transcoder options you didn't set from Preferences.xml.
2. Sign out of all devices from your Plex account settings and change your Plex password. If the chain ran, the attacker had your server's owner token.
3. Treat anything the Plex service account could reach as exposed, including mounted shares and credentials stored on the same machine or VM.

Who is not in scope

• Servers already on 1.43.3.10861 or newer. Plex says they are not affected. If a server was exposed and unpatched before you updated, the compromise checks above still apply.
• Plex apps on your TV, phone or browser. The chain runs against the server. Plex shipped security fixes for Plex Desktop 1.115.0 in the same round, so update it too, but the chain targets the server.
• Servers nobody outside your network can reach are out of the path of the internet-wide attacks Plex describes. The chain still works for anyone on your LAN, so update those as well.

What this is not

This is not an attack on Plex's cloud or on plex.tv itself. The chain runs against servers people host themselves, one unpatched server at a time.

The details

• CVEs in the chain: CVE-2026-96652 (SSRF via /player/timeline, CWE-918), CVE-2026-96654 (unescaped identifier in searchOne lets an attacker call other plugins' functions, CWE-84), CVE-2026-96655 (CWE-918; the CVE record describes SSRF through the /video/:/transcode/universal path parameter, while Plex's table summarizes it as disclosure of the owner's admin token), CVE-2026-96656 (admin can write files that run on load via TranscoderH264Options, CWE-73).
• Severity as published: CVSS 4.0 scores of 5.3, 6.9, 5.3 and 8.6 respectively. Those score each bug alone. Plex says the chain gives an unauthenticated remote attacker code execution.
• Related, not on KEV: CVE-2026-96651, a path traversal in /system/agents/media/get that lets a user with a valid session read files including the PlexOnlineToken. Same fix version.
• Affected: Plex Media Server before 1.43.3.10861. Plex's advisory title says v1.43.2 and earlier.
• Timeline: reported to Plex July 27. Plex confirmed and paid a bounty August 4. Plex announced the 1.43.3 update September 1 without details. CVEs published September 23. Write-up and proof of concept public October 16. First in-the-wild exploitation seen October 17. Plex confirmed widespread exploitation October 19. CISA KEV October 20.
• KEV: CISA's federal due date is October 23 for CVE-2026-96654 and CVE-2026-96656, and November 3 for CVE-2026-96652 and CVE-2026-96655. Known ransomware use is listed as Unknown. CVE-2026-96656 is flagged for forensic triage under BOD 26-04, which means agencies have to look for compromise, not only patch.

References

• Plex: Important Security Update for Plex Media Server v1.43.2 and earlier (with the October 19 exploitation update)
• zmain: Plex2Shell, unauthenticated RCE in Plex Media Server and code-zm/plex2shell
• boredhackerblog: Plex vulnerabilities being exploited in the wild to drop a cryptominer
• CISA Known Exploited Vulnerabilities catalog (four Plex CVEs added 2026-10-20)
• CISA CSAF advisory VA-26-266-01
• NVD: CVE-2026-96652, CVE-2026-96654, CVE-2026-96655, CVE-2026-96656