Criminals started using a public exploit chain against unpatched Plex Media Server installations within roughly a day of its release, dropping cryptocurrency miners and proxy software. For UK organisations the miner is the least of it: an exposed media box on a home worker’s broadband line can become a residential exit point for someone else’s login attempts.
What happened
On 16 October 2026 the researcher Zach Main published a technical write-up and proof-of-concept code for Plex2Shell, his name for four chained weaknesses in Plex Media Server: CVE-2026-96652, CVE-2026-96654, CVE-2026-96655 and CVE-2026-96656. Used together, they give an unauthenticated attacker code execution on an internet-reachable server, running with whatever privileges the Plex service has.
The disclosure itself was handled properly. Main reported the issues to Plex on 27 July, along with a fifth bug, CVE-2026-96651, according to The Hacker News. Plex confirmed the findings and paid a bug bounty on 4 August, and the fixed build is Plex Media Server 1.43.3.10861. Accounts of exactly when that build shipped vary: The Hacker News gives 3 August, while SecurityWeek reports that Plex’s 1 September advisory told owners the fixes were already out and asked them to upgrade. Either way, the patch had been out at least six weeks before the exploit went public.
That did not help anyone who had not updated. A researcher who blogs as boredhackerblog runs an internet-facing Plex honeypot on a vulnerable release, which until then had mostly drawn reconnaissance and generic scanning. On 17 October it was compromised using the public exploit, possibly with some changes. SecurityWeek, The Hacker News and CyberSecurityNews reported the activity on 19 October.
The technical picture
None of the four flaws is catastrophic alone. Their CVSS scores range from 5.3 to 8.6, which is why chained bugs like these get deprioritised in patch queues.
According to the published analysis, the chain starts with a server-side request forgery in the player timeline handling, where an unvalidated parameter lets an outsider make the server send requests to destinations they choose. A second weakness, in a search endpoint, lets that forged traffic reach internal plugin functions and recover the owner’s administrative token. With owner rights, a third request forgery in the transcoding path pulls in attacker-hosted content. The fourth flaw, a lack of control over file names and paths, lets that content land in the server’s Codecs directory. Plex then runs it the next time it transcodes media. The exploit supports Linux and Windows; the honeypot was a Linux deployment in Docker.
The first payload was an XMRig-based miner, which The Hacker News reports ran as a process called “mylovelyminer” and pointed at a mining server under the proxystream[.]st domain. According to The Hacker News, Bitsight linked a sibling subdomain to the AISURU botnet in August, though nobody has formally attributed the Plex activity. Later on 17 October a second program, “myawesomeproxy”, appeared. VirusTotal classifies it as a stealthy Linux backdoor and reverse proxy. Its banner tells the person running it that their internet traffic may be used by others.
Two caveats matter. The researcher stresses that the published indicators reflect a single honeypot, so they should not be treated as a complete list. And while Reddit users have reported the same miner on their Plex servers, The Hacker News says it is not yet known whether those infections came through Plex2Shell.
Why it matters for UK organisations
It would be easy to dismiss this as a home media problem. I think that would be a mistake, for three reasons.
First, the proxy payload is the real story. As the researcher put it, Plex often sits on residential IP addresses, which are valuable to anyone trying to reach “corporate VPNs and emails” without tripping location or reputation checks. Many UK conditional access and fraud rules trust domestic broadband far more than hosting ranges. A hijacked media server on an employee’s home connection gives an attacker that kind of address, and it sits on the same network as a corporate laptop.
Second, Plex is not only found at home. Small offices and venues sometimes run it on NAS appliances and spare servers, and these boxes are often exposed through router port forwarding that nobody remembers setting up. Cord Cutters News reports that scans in September found more than 36,000 internet-facing instances still on vulnerable builds. I have not seen a UK-specific breakdown, but there is no reason to think British networks are any cleaner.
Third, NAS and Docker installations often lag behind. Package centres and container images do not always pick up new Plex builds quickly, and NAS owners may need to update by hand. That population is the most likely to be exposed now.
Expert view
In my experience, the dangerous window is not the period after a bug is reported. It starts when a working exploit is published, and here it lasted about a day. What failed was the assumption, common among owners of self-hosted kit, that the box looks after itself.
When we test home-working arrangements and small sites, unmanaged services exposed through consumer routers come up again and again. They rarely appear in an asset register and sit outside most vulnerability scanning. Plex2Shell is a textbook case of medium-rated flaws adding up to a full compromise, and of a “personal” service creating corporate risk through the network it shares.
I would also caution against reading “cryptominer” as “low impact”. The miner pays the operators today; the backdoor and proxy let them, or their customers, return later.
What to do now
- Update every Plex Media Server to 1.43.3.10861 or later and check the version that is actually running, especially on NAS appliances and Docker hosts, where updates may be manual. Treat any earlier build as vulnerable. This maps to the Cyber Essentials security update management control.
- Remove unnecessary exposure. If remote access is not needed, turn it off and close any port forward to TCP 32400. Where it is needed, restrict it. This is Cyber Essentials firewall and secure configuration territory.
- Hunt for signs of compromise. Look for unexpected child processes of the Plex binary, unfamiliar files in the Codecs directory, processes such as myawesomeproxy or mylovelyminer, and unexplained CPU load or outbound traffic. Base detections on behaviour rather than fixed indicators, because filenames, ports and domains can change easily.
- Rebuild, do not clean. If a server shows signs of compromise, reinstall from a known-good state and rotate any credentials the host could reach, including the Plex account.
- Tighten home-working guidance. Remind staff that self-hosted services on home networks are in scope for your security policy. Consider separating corporate devices from home servers, for example with a guest network.
- Review identity signals. Do not treat a residential UK IP address as evidence that a login is genuine. Pair location rules with phishing-resistant MFA and device compliance checks.
Bottom line
Plex2Shell was disclosed responsibly and patched well before the exploit went public, and attackers were still using it within a day. Any organisation whose staff, offices or suppliers run Plex should confirm it is on 1.43.3.10861 or later today. They should also treat any internet-exposed instance that was not updated by mid-October as possibly compromised and a potential proxy into their own estate.
Sources
- SecurityWeek: Plex2Shell Exploit Chain Weaponized Against Plex Servers Hours After Disclosure
- The Hacker News: Hackers Exploit Plex2Shell Flaws to Install Crypto Miners and Linux Proxy Backdoor
- CyberSecurityNews: Hackers Exploiting Plex Vulnerabilities in the Wild to Deploy Cryptominer Malware
- Cord Cutters News: Plex Media Server Owners Urged to Update Immediately After In-the-Wild Exploitation
