Plex2Shell Exploits Target Unpatched Plex Servers With Crypto Miners and Proxy Malware

Plex fixed these bugs about seven weeks ago. The servers at risk are the ones that never got the update.

What happened​

Researcher Zach Main published the technical write-up and public proof of concept for Plex2Shell on October 16. Attacks started within a day. SecurityWeek reported that threat actors began targeting Plex2Shell, a chain of four Plex Media Server vulnerabilities, one day after technical details and a working exploit went public.

The chain uses four CVEs: CVE-2026-96652, CVE-2026-96654, CVE-2026-96655 and CVE-2026-96656. According to SecurityWeek, they can be combined to run arbitrary code on an exposed server without valid credentials. The code runs with the same privileges as the Plex service. In plain terms, anyone who can reach your server from the internet doesn't need a password to run their own code on it.

The first confirmed exploitation came from the researcher behind BoredHackerBlog, who runs a deliberately vulnerable Plex honeypot. Boredhackerblog recorded successful exploitation of a Linux-based Plex Media Server honeypot running in Docker. Before October 17, the honeypot had mostly seen reconnaissance scans and generic attack attempts. Then, in the researcher's own words to SecurityWeek, "As of this morning (Oct 17th), I finally saw in the wild exploitation".

Disclosure timeline​

This isn't a zero-day. The fix was out more than six weeks before the exploit code went public. Once a PoC lands on GitHub, an unpatched server that's reachable from the internet is an easy target.

Section summary: Four flaws, chained together, give an attacker remote code execution without logging in. Plex patched them on September 1. Public exploit code appeared October 16, and attacks followed the next day.

How the chain works​

Here is the short version. Cyber Security News, summarizing the Plex2Shell repository, says the chain starts with server-side request forgery, which tricks Plex into sending requests chosen by an attacker. It then reaches internal functions, gains access to owner-authorized requests, and writes a file to an attacker-selected location. The final stage abuses the loading of an unsigned codec to execute code.

That last step explains why cleanup is tricky. The malicious file lands in Plex's Codecs directory, and Plex loads codec libraries from there when the transcoder starts. Kill the miner process and it can come back the next time someone starts a transcoded stream. Your family's movie night ends up relaunching the malware.

Daily CyberSecurity lists the highest individual score as 8.6 (High ?? CVSSv4), for the arbitrary file write flaw. Other reporting attributes a 9.8 CVSS 3.1 score for the whole chain to the researcher's own assessment. That figure is not an official rating.

What the attackers dropped​

The payloads say a lot about who's doing this: opportunistic operators who want to make money from someone else's hardware.

• A cryptominer. SecurityWeek reports the attackers were observed dropping a cryptocurrency miner built on XMRig. Once the honeypot was allowed outbound connections, the researcher saw downloads from 217.60.194[.]116 involving files named docker and x.
• A proxy tool called myawesomeproxy. It appeared later the same day. SecurityWeek says the researcher identified it as proxy software, and it shows a notice saying that anyone running it agrees to the potential use of their internet traffic.

The proxy is the more serious of the two. A miner costs you electricity, performance and probably some fan life. A residential proxy puts your IP address on someone else's traffic. The researcher put it this way: "Plex may be hosted on residential IP and I think threat actors would love to have residential IP proxy to access corporate VPNs and emails". That's a possible abuse scenario, not a documented one. The reporting doesn't show what specific downstream use, if any, has happened.

The exploitation attempts came from several addresses. The first attempt originated from 45.194.92[.]222, with further attempts involving 91.92.40[.]202 and 176.65.139[.]228. Treat these as a starting point only. The researcher cautioned that the published indicators of compromise cover only activity seen on the honeypot.

User reports, and what they don't prove​

The findings spread on Reddit, where Plex owners were asked to check their own servers. Neowin rounded up some of the replies:

• One user said their server rack had become unusually loud, with the CPU cooler near full speed. They then found an older Plex install running a process named mylovelyminer.
• Another user reported a miner named x12345.
• A third described suspicious requests and changed Plex settings in their server logs.

Low-power media servers make the problem easy to feel. Many Plex boxes are NAS units or small PCs with modest CPUs that rely on the integrated GPU's media engine for transcoding. A miner taking most of the CPU leaves little for anything else. One detailed account of the honeypot says the miner used about 97% of its CPU.

Keep some perspective, though. A loud fan doesn't prove an infection, and finding none of these names doesn't prove a server is clean, because attackers rename their tools. Several outlets also note that the available evidence does not establish how many real servers have been compromised or identify the attackers behind the activity. The honeypot and the user reports confirm that attacks are happening. They don't tell us how widespread they are.

There's a platform gap too. The confirmed honeypot ran Linux in Docker, and the miner names reported so far come from that kind of setup. Nothing published yet shows what payloads, if any, attackers are dropping on Windows Plex installs. The vulnerable version range is what matters, and Plex's notice includes update instructions for Windows along with the other platforms.

Section summary: Attackers dropped an XMRig-based miner and a residential-proxy tool. Reddit users report similar miners on real servers. The scale is unknown, and the indicators so far come mainly from one Linux Docker honeypot.

What to do now​

1. Update Plex Media Server​

Plex's September notice covers Plex Media Server 1.43.2 and earlier and tells owners to run 1.43.3 or newer. Several outlets name the specific fixed build. Daily CyberSecurity, for example, advises readers to Update to 1.43.3.10861. Check the version your server actually reports. Don't assume your package manager or container tag pulled it.

• NAS owners: Its official security notice warned that NAS users might need to install updates manually. If your vendor's app store hasn't caught up, follow Plex's manual installation instructions for your platform.
• Docker users: The confirmed victim was a container. Make sure the image you're running includes the fixed build, not an old pinned tag.
• Plex Desktop users: The September release also included Plex Desktop 1.115.0, so update that too.

2. Check whether you're already compromised​

Before or alongside patching, look for:

• CPU use that stays high while nobody is streaming
• Unfamiliar processes, including the names reported so far: mylovelyminer, x12345, myawesomeproxy, or files named docker and x
• Unexpected library files in Plex's Codecs directory
• Plex settings you didn't change, and odd requests in Plex's logs
• Outbound connections to the addresses listed above, or to mining pools

On Windows, Task Manager and Resource Monitor are a reasonable first pass for sustained CPU load and strange processes. Don't count a clean result as proof, for the reasons above.

3. If you find something, treat it as an incident​

Killing the miner isn't enough, because the payload can relaunch from the Codecs directory when transcoding starts. Neowin and other detailed reports recommend investigating properly, rebuilding the server from a trusted state, and changing credentials that may have been exposed, including your Plex account password, then signing out other devices. These recommendations come from the reporting, not from Plex's September notice, but they're sensible. The code ran with the Plex service's privileges, so assume the attacker could see anything that service could.

4. Cut down your exposure​

Does your Plex server really need to be reachable from the public internet? The confirmed attack hit an internet-facing server. One option is a private overlay network such as Tailscale. You install it on the server and on the devices you watch from, and you get remote access without a public port forward. Neowin notes this can sometimes stand in for Plex's usual remote-access setup for personal use, but client compatibility and playback restrictions vary, so test it before you rely on it.

Reducing exposure is not the same as patching. It lowers the chance of being hit, but it won't fix a vulnerable build and it won't clean a server that's already infected.

Section summary: Install 1.43.3 or newer (build 1.43.3.10861 or later), checking manually on NAS and Docker. Look for signs of compromise. Rebuild and change credentials if you find any, then think about taking Plex off the public internet.

The bigger picture​

This follows a familiar pattern: a vendor patches quietly, the researcher waits a reasonable period, the PoC comes out, and attackers move within hours. Plex handled its part about as well as a vendor can. It paid a bounty, shipped a fix and told users to update. Main waited about six weeks after the fix before publishing.

The weak point is the home server. Many hobbyist boxes are set up once and then left alone, NAS app stores lag behind, and Docker images sit on old tags. Self-hosted servers usually get none of the update management a company laptop does.

Plex has been here before. Its 2022 breach and the LastPass incident linked to an unpatched Plex install on an engineer's home machine showed how a media server can turn into a way into much more valuable systems. The residential-proxy payload in this campaign points the same way, even if it's only a possibility for now.

Bottom line​

If your Plex Media Server is older than 1.43.3, update it today. Check that the update actually installed, look for signs of compromise, and ask whether it needs to be on the open internet at all. Attackers are already trying these servers, and a server that runs hot and slow can also be routing other people's traffic through your connection.