RC RANDOM CHAOS

code-zm published plex2shell, a Plex RCE exploit

Chained Plex Media Server bugs are being exploited in the wild to drop XMRig miners and a residential proxy on vulnerable servers.

· 3 min read
code-zm published plex2shell, a Plex RCE exploit

Plex shipped security fixes for Media Server v1.43.2 and earlier on September 1, 2026, announced by email and a forum post that was short on detail. The CVEs followed on September 26: CVE-2026-96652, CVE-2026-96654, CVE-2026-96655, and CVE-2026-96656, none scoring above 9. The payoff came on October 16, when a researcher publishing as code-zm released a write-up called plex2shell describing how to chain several of those bugs into remote code execution, with working code on GitHub. A honeypot running a vulnerable Plex version started catching real exploitation the next morning.

The request

The first attempt came from 45.194.92.222. The request hits /player/timeline/subscribe with a protocol parameter pointing back at the server’s own API on 127.0.0.1:32400, which then reaches /system/agents/.../GetResultFromNetwork carrying a url parameter aimed at an attacker host via sslip.io. The server is talked into fetching attacker-controlled content through its own trusted internal endpoints, and the chain ends in code execution. The user agent was Python-urllib/3.10, so this is scripted, not hand-driven.

Two more IPs were seen running the same exploitation: 91.92.40.202 and 176.65.139.228.

The payloads

The honeypot blocked outbound traffic by default, which cost the operator some payload captures until they opened egress. Once they did, they saw a download from 217.60.194.116. The Docker artifact held a cryptominer, XMRig. Expected, and mostly a problem for the victim’s power bill.

The second payload is the one worth attention. A binary called myawesomeproxy turns the compromised host into a network proxy. It states its purpose on startup: “Running this software on any of your devices makes you agree to the potential external use of your internet traffic.” Observed traffic tied back to proxystream.st.

This is why Plex is an attractive target beyond free compute. These servers frequently sit on residential IPs, and residential egress is exactly what buyers of proxy access pay for, because it reaches corporate VPNs and webmail that reject datacenter ranges. A miner costs the owner electricity. A residential proxy quietly routes someone else’s traffic, including whatever that someone else is doing, through the owner’s connection.

What to do

Update Plex Media Server past v1.43.2 if you have not. The exploited versions are the ones Plex flagged on September 1.

The exploit depends on the server making outbound requests as part of the chain, so restricting egress from Plex hosts both blunts the attack and denies payload delivery. The honeypot operator saw the difference directly: with outbound traffic blocked the exploitation attempts landed, but the follow-on download did not.

Hunt for the known payloads and infrastructure:

  • Exploitation sources: 45.194.92.222, 91.92.40.202, 176.65.139.228
  • Payload host: 217.60.194.116
  • proxystream.st in outbound connections

File hashes from the honeypot:

5712ef510481f15fe8b18fdd10b73026d57cb3d9d151878a692358b99a464441 docker
68938fb428f2bcfef4ede62f7b29cd0f15f37ed59e94462c099f2ca64e36baa7 x (upx packed)
b20f39fc00d242e706b6c30367ad811c676e0575050a4ec2f30104b696944b49 x (upx unpacked)
e546b10aee5edc754da4f9b0baace00392257121911f630145078eafad1e6bd9 myawesomeproxy
2d3c618b21a7e2f8bcd735da188e44a7609ff3f204832dd0781cd09e4388c9db xmrig

For signatures, BoredHackerBlog published lab pcaps at github.com/BoredHackerBlog/plex2shell_pcap, and code-zm, who found the bugs, published detection rules at github.com/code-zm/plex2shell/tree/main/detection.

Share

Keep Reading

Latest on the Wire

Full wire →

New signal daily · RSS

Stay in the loop

New writing delivered when it's ready. No schedule, no spam.