Plex2Shell: Outdated Plex Media Servers Hijacked to Mine Monero and Resell Bandwidth

A four-CVE chain Plex fixed on September 1 went from public proof-of-concept to in-the-wild attacks in under a day. Servers on 1.43.2 or earlier are being turned into XMRig miners and proxy nodes.

The Proof DeskOct 19, 2026 · 6 min read

Text cover reading Plex2Shell: patched in September, exploited in October, over a dark navy background

Anyone still running Plex Media Server 1.43.2 or earlier with port 32400 open to the internet is being actively targeted right now. A chain of four vulnerabilities, published as Plex2Shell on October 16, 2026, lets an unauthenticated attacker run code on the server, and a honeypot running an old Plex build was exploited the very next morning.

The attackers did what attackers usually do with a cheap foothold: they installed an XMRig Monero miner and a proxy tool that rents out the victim's home internet connection. The frustrating part is that none of this is a zero-day. Plex shipped the fix in Plex Media Server 1.43.3 on September 1, about seven weeks before the attacks started.

Exploited within a day of the public write-up

Security researcher Zach Main published the full Plex2Shell write-up and a proof-of-concept on GitHub on Friday, October 16. The researcher behind BoredHackerBlog, who runs an internet-facing Plex honeypot, had mostly seen scanning and generic exploit attempts until then. On Saturday, October 17, that changed: "As of this morning (Oct 17th), I finally saw in the wild exploitation."

The first hit came from 45.194.92.222 using a Python-urllib/3.10 user agent and followed the exact request pattern described in the write-up. Two more addresses, 91.92.40.202 and 176.65.139.228, were seen doing the same. Once the honeypot was allowed to make outbound connections, it pulled down two files from 217.60.194.116 and started mining.

What Plex2Shell is

Plex2Shell links four CVEs in Plex Media Server, all fixed in build 1.43.3.10861. None of them looks critical on its own. Chained together, they give remote code execution with no login and no user interaction.

CVE-2026-96652 (CVSS 4.0: 5.3) - a server-side request forgery in /player/timeline. The endpoint only checks that an X-Plex-Token header is present, not that it is valid, so any junk value gets through.
CVE-2026-96654 (CVSS 4.0: 6.9) - a broken authorization check that lets a request coming back from the server itself reach the internal /system/agents/* API and call other plugins' functions.
CVE-2026-96655 (CVSS 4.0: 5.3) - a second SSRF, in the /video/:/transcode/universal path, available to authenticated users.
CVE-2026-96656 (CVSS 4.0: 8.6) - an admin user can write arbitrary files that may be executed on load.

In plain terms, the attacker first gets the server to make a request to itself. That internal request reaches the bundled TheTVDB metadata agent, which attaches the owner's admin token to any URL that starts with http://127.0.0.1. Because the check is only a prefix match, a hostname that begins with those characters but resolves to the attacker's machine receives the token. With an admin token in hand, the attacker changes a transcoder setting so that a file lands in Plex's Codecs directory. Plex loads every .so library in that folder when the transcoder starts, with no signature check, so the planted file runs.

Why the scores look low

The four CVEs top out at 8.6. The researcher's own rating for the full chain is CVSS 3.1 9.8 (network, no authentication, no user interaction). That 9.8 is not an official score, but it is a better guide to the real risk than any single CVE.

From bug report to live attacks

July 27, 2026 - Zach Main reports the issues to Plex security.
August 4 - Plex acknowledges the report and pays a bug bounty.
September 1 - Plex releases Plex Media Server 1.43.3 and Plex Desktop 1.115.0, posts an "Important Security Update for Plex Media Server v1.43.2 and earlier" notice and emails server owners.
September 23 - the four CVEs are published.
October 16 - the full write-up and the public proof-of-concept go live.
October 17 - the first in-the-wild exploitation is seen on the BoredHackerBlog honeypot.
October 18 - the honeypot operator asks r/PleX whether other users have been hit.

The researcher credits Plex with a quick response. Plex's September notice told owners to "update to the latest version as soon as possible", but at the time it did not explain the bugs, and the CVEs only appeared three weeks later. Many owners who skipped that update had little reason to think it mattered until the proof-of-concept went public.

What the attackers installed

The first dropper, a script named docker, downloaded a second file named x and ran it as a miner pointed at ota.proxystream.st:3333 with the rig ID plexdocker. "Of course it's a cryptominer," the honeypot operator wrote. The binary is a UPX-packed build of XMRig, the common open-source Monero miner.

Honeypot wget log entries dated 2026-10-17 showing repeated, retried download attempts of http://217.60.194.116/x and http://217.60.194.116/docker — The compromised honeypot retrying downloads of the miner and its dropper from 217.60.194.116. Source: BoredHackerBlog

Later that day, at 19:58 GMT, a second-stage loader arrived from 77.90.185.205. It is a short shell script that uses a lock file so it runs only once, then installs the miner under the name mylovelyminer.

Wireshark Follow HTTP Stream window showing a GET /m/sh request to 77.90.185.205 and the returned shell script with LOCKFILE=/tmp/xsetup.lock and NAME=mylovelyminer — The second-stage loader captured on October 17 at 19:58 GMT. Source: BoredHackerBlog

Alongside the miner, the attackers ran a second tool called myawesomeproxy, also under the Plex service account. When it starts, it prints: "Running this software on any of your devices makes you agree to the potential external use of your internet traffic." In practice, that means the victim's home connection is resold as a residential proxy exit, so other people's traffic leaves the internet from the victim's IP address.

Process list on the compromised server showing the Plex TheTVDB plug-in next to ./myawesomeproxy plex and ./mylovelyminer788 --rig-id plex using 97.1 percent CPU — The miner and the proxy running beside Plex's own TheTVDB plug-in. Source: BoredHackerBlog

On the honeypot, the miner used about 97% of the CPU. The operator also pointed to Bitsight research on the Aisuru botnet that mentions proxystream.st traffic. That is a lead worth watching, not a confirmed attribution, and no threat actor has been named.

Who is at risk

Any Plex Media Server older than 1.43.3.10861 that can be reached from the internet on port 32400 is exposed. Cord Cutters News reports that scanning platforms counted more than 36,000 internet-facing Plex Media Server instances in September 2026. It does not say how many of those were already patched.

The most likely victims are servers that never update on their own: Docker images pinned to an old tag, NAS packages that trail Plex's own releases, and home servers set up years ago and left alone. Plex Desktop 1.115.0 was patched in the same release but is not part of this chain.

What to do now

Update Plex Media Server to 1.43.3.10861 or newer. Plex's September 1 forum post has steps for Windows, macOS, Linux, NAS, Docker and NVIDIA Shield. Check the version shown in Plex's own settings rather than trusting your package manager or container tag.
Do not expose port 32400 to the internet unless you really need remote access. If you do, put it behind a VPN or a reverse proxy you control.
Run Plex as a low-privilege user or inside a container, so a compromise of Plex does not mean a compromise of the whole machine.
Look for signs of compromise: unexpected .so files in Plex's Codecs directory, processes named mylovelyminer*, x12345 or myawesomeproxy, sustained high CPU use, and outbound connections to ota.proxystream.st:3333.
If you find any of these, rebuild the server from a clean state, then rotate your Plex account password and sign out all devices so the stolen admin token stops working.

For defenders

The proof-of-concept repository includes detection rules, and the BoredHackerBlog operator has published packet captures of the real attacks. Both are linked in the sources below.

Indicators of compromise

These indicators come from the BoredHackerBlog honeypot. Attacker infrastructure changes quickly, so treat them as a starting point rather than a complete list.

# SHA-256
docker                    5712ef510481f15fe8b18fdd10b73026d57cb3d9d151878a692358b99a464441
x (UPX-packed)            68938fb428f2bcfef4ede62f7b29cd0f15f37ed59e94462c099f2ca64e36baa7
xmrig (unpacked)          b20f39fc00d242e706b6c30367ad811c676e0575050a4ec2f30104b696944b49
xmrig (second update)     2d3c618b21a7e2f8bcd735da188e44a7609ff3f204832dd0781cd09e4388c9db
myawesomeproxy            e546b10aee5edc754da4f9b0baace00392257121911f630145078eafad1e6bd9

# Exploitation sources
45.194.92.222
91.92.40.202
176.65.139.228

# Payload hosts
217.60.194.116
77.90.185.205

# Mining pool
ota.proxystream.st:3333

Frequently asked questions

Is Plex2Shell a zero-day?

No. Plex fixed it in Plex Media Server 1.43.3 on September 1, 2026, about seven weeks before the first attacks. Only servers that were never updated are affected.

Which Plex version fixes it?

Build 1.43.3.10861 or newer. Plex's notice describes v1.43.2 and earlier as affected.

Do attackers need my Plex password?

No. The chain starts with a request that only needs some value in the token header, not a valid one, and then steals the owner's real admin token from the server itself.

Am I safe if remote access is turned off?

Your risk is much lower, because the attack needs to reach port 32400. Anyone on your local network could still try it, so update anyway.

How do I know if my server was hit?

Look for constant high CPU use, unknown processes such as mylovelyminer or myawesomeproxy, new .so files in Plex's Codecs directory, and connections to ota.proxystream.st on port 3333. The hashes and IP addresses above can be checked against your logs and security tools.

Does a Plex Docker container protect me?

It limits the damage but does not stop the attack. The rig ID plexdocker in the dropper suggests containers were an expected target, so pull an updated image and confirm the server version inside it.

Sources

Key takeaways

Plex2Shell chains four CVEs into unauthenticated remote code execution on Plex Media Server 1.43.2 and earlier.
The fix shipped on September 1, 2026; attacks began on October 17, less than a day after the public proof-of-concept.
Compromised servers get an XMRig Monero miner and a proxy tool that resells the owner's internet connection.
Update to 1.43.3.10861 or newer, keep port 32400 off the open internet and check for the indicators listed above.