Plex patched this in August. Exploit code dropped Friday and 49,000 servers were still open.

If you run Plex Media Server and haven’t updated since July, stop reading and go update it. Then come back.

Technical details and working exploit code for a four-bug chain in Plex went public on October 16. A honeypot operator watched attackers using it the next day. Shadowserver’s scan data had roughly 49,000 servers still exposed as of Saturday, about 25,100 of them in North America.

The fix shipped in early August.

What the chain does

Four bugs, used in order, get an unauthenticated attacker from “can reach your server” to “runs code on your server”:

• CVE-2026-96652 (CVSS 5.3), unauthenticated server-side request forgery through the /player/timeline endpoint.
• CVE-2026-96654 (6.9), a flaw in the searchOne endpoint that hands over the server owner’s admin token.
• CVE-2026-96655 (5.3), authenticated SSRF through /video/:/transcode/universal, reachable once the previous step produced a token.
• CVE-2026-96656 (8.6), file path control that lets an attacker drop an ELF shared object into Plex’s Codecs directory.

None of those four is catastrophic alone. Chained, the last one is the problem: code in the Codecs folder runs the next time Plex transcodes something. Your own media library triggers it.

That’s also why killing the process doesn’t fix a compromised server. The payload sits in Codecs and runs again on the next transcode.

What’s being dropped

Two things, per the reporting. A Monero miner called mylovelyminer, pointed at infrastructure under proxystream. And myawesomeproxy, a Linux backdoor and reverse proxy that routes other people’s traffic through your connection. Bitsight flagged a related subdomain back in August in connection with the AISURU DDoS and proxyware botnet.

So the miner costs you electricity. The proxy makes your home IP the apparent origin of whatever somebody else is doing.

The timeline is the actual story

Zach Main reported the bugs to Plex on July 27. Plex shipped the fixed build, 1.43.3.10861, in early August and paid a $500 bounty. Plex posted a public advisory on September 1 and emailed users running older versions. CVEs were assigned September 23. Technical details went public October 16. Exploitation started October 17.

That’s roughly ten weeks of warning, including a direct email, and 49,000 servers were still sitting there when the exploit code landed. The gap between a patch existing and a patch being applied is the entire window these campaigns run in, and here it was measured in weeks with a reminder in the middle of it.

What to do

Update to 1.43.3.10861 or newer. Check Plex’s Codecs directory for anything you didn’t put there, because an update alone doesn’t remove a payload that already landed.

Then ask the harder question: why was it reachable from the internet at all?

We’ve said this in the QNAP guide and again about FortiGate, and it keeps being the same sentence. The vulnerability is the headline. The reason it became an incident is that the service was listening on a public address while a patch sat unapplied.

Plex makes this particular trap easy to fall into, because remote access is close to zero-configuration and most people turn it on without thinking of it as exposing a server. It is exposing a server. If you don’t genuinely need people outside your house reaching your library, turn remote access off and get to it over a VPN instead. If you do need it, the update is not optional and neither is watching for the next advisory.

Sources: The Hacker News on the Plex2Shell chain and the payloads, Gizmodo on the disclosure timeline and Shadowserver’s exposure numbers.