Plex2Shell Recruits Home Servers as Residential Proxies

Plex said internet-facing servers older than 1.43.3.10861 are seeing widespread Plex2Shell attacks that drop miners and home-network proxies. The company updated its own advisory after a public write-up on October 16, 2026, and told owners of reachable old builds to assume a breach.

The bugs were patched in August. The payload that pays is not only a Monero miner. It is a Linux reverse proxy that rents the living-room IP sitting behind a media box that never sleeps.

Four Flaws and a Loopback Trick

Security researcher Zach Main chained four Plex Media Server flaws into what he calls a five-stage unauthenticated RCE chain. Each bug looks moderate on its own. Together they let anyone who can reach port 32400 run code as the Plex service account, with no real login.

Main rates the full chain 9.8 on CVSS 3.1 in his proof-of-concept notes. CISA, which assigned the records, scored the pieces on CVSS 4.0 from 5.3 up to 8.6. The National Vulnerability Database lists Plex Media Server before 1.43.3.10861 as affected.

THE FOUR BUGS IN THE CHAIN

Plex later wrote that chained together, these issues let an unauthenticated remote attacker run code with the privileges of the Plex Media Server process.

The Timeline Endpoint Trusts Any Token

Plex Media Server listens on port 32400 and is often forwarded so people can watch from outside the house. Main’s write-up shows the companion-player path only checks whether an X-Plex-Token header exists, not whether the value is valid. Sending a junk token is enough to get past the gate.

The protocol field in /player/timeline is copied raw into a callback URL. An attacker can put a full loopback address in that field, then force the server to POST to itself. Requests that appear to come from 127.0.0.1 skip a lot of auth, including the /system/agents plugin API. A broken guard on searchOne then lets the attacker call plugin functions that should stay internal.

One of those functions, GetResultFromNetwork in the bundled TVDB agent, fetches a URL. If the URL string starts with http://127.0.0.1, Plex attaches the owner’s admin token. Main used a hostname that begins with 127.0.0.1 and still resolves, via sslip.io, to the attacker. The listener receives a local-* owner token and can read preferences, change settings, and start transcodes.

The Transcoder Writes a Shared Library

With that token, the last two bugs turn admin rights into a running process. The owner can set TranscoderH264Options, a string Plex appends to its bundled x264 encoder. The dump-yuv debug switch writes decoded frames to any path. Set qp=0 and those frames are a bit-exact copy of the input, so a lossless “video” can be an ELF shared object.

The file lands in the Codecs set-directory. At the next transcode, Plex’s libavutil loads every.so in that folder with dlopen, with no signature check, no execute bit, and no required symbol. A constructor-only library still runs. Main’s PoC forks a reverse shell as uid plex. CVE-2026-96656 is the file-write step, and CISA gave it a CVSS 4.0 score of 8.6.

Miners Arrive With a Home Proxy

A researcher who writes as boredhackerblog stood up an old Plex build as a honeypot after Plex’s September notice and waited for Main’s post. On the morning of October 17, 2026, the published exploit showed up in live traffic, with the user-agent Python-urllib/3.10 and the same sslip.io token-leak URL Main documented.

Three source addresses hit the box: 45.194.92.222, 91.92.40.202, and 176.65.139.228. After outbound traffic was allowed, the honeypot pulled payloads from 217.60.194.116. First came a miner staged as x12345. Later the same day a binary named myawesomeproxy was running, along with an XMRig process named mylovelyminer whose pool pointed at ota.proxystream.st.

When myawesomeproxy starts, it prints a one-line notice that reads like a terms-of-service joke and works like a confession.

Running this software on any of your devices makes you agree to the potential external use of your internet traffic

myawesomeproxy banner, captured on the boredhackerblog honeypot

Nick Percoco, chief security officer at Kraken, put the same finding in plainer words after the honeypot write-up: the operators are dropping a residential proxy, which means the home IP gets rented out to criminals. A miner burns CPU while someone is watching a show. A proxy sells the address itself, all day, including when the TV is off.

Why Attackers Want a Living-Room IP

Home Plex boxes sit on residential connections that look like ordinary people to banks, mail hosts, and corporate VPNs. boredhackerblog wrote that threat actors would love a residential IP proxy to reach those services, and the honeypot then saw exactly that class of tool. The miner is noisy. The proxy is inventory.

The mining pool and the proxy both talk to the proxystream.st zone. In August 2026, Bitsight TRACE flagged global.relay.proxystream.st among Aisuru botnet proxyware C2 domains, alongside 5gf7jtfk0y.st, with bots resolving a random A record and connecting on port 8001. Bitsight had watched Aisuru since February 2026 as a volumetric DDoS fleet that also carries a PROXY command, turning an infected device into a raw TCP/UDP relay rather than sending traffic through the C2 itself.

That is not proof the Plex operators are the Aisuru botmasters. It is a shared naming and hosting pattern in a market that already treats compromised TVs, streaming boxes, and always-on NAS units as rented exits. Aisuru’s documented proxyware was aimed at consumer devices with clean home addresses. A Plex server that has been online for years, with a stable ISP lease, is the same kind of product.

Tens of Thousands Still Run Old Builds

Plex is not a rare appliance. It is software people install on a PC, a Synology or QNAP NAS, a Docker host, or an NVIDIA Shield, then forget until a movie fails to play. Remote Access and a forwarded 32400 port make the chain reachable from the internet. Main called that a large attack surface on a single port.

SHADOWSERVER COUNTS ON EXPOSED PLEX

• Early September: The Shadowserver Foundation scanned nearly 300,000 internet-exposed Plex instances worldwide, including 134,800 in the United States.
• September 4, 2026: After Plex’s public warning, Shadowserver began daily scans for unpatched Media Server builds.
• September 9, 2026: More than 36,000 of those internet-facing copies still ran versions Plex had already called unsafe.
• Safe line: 1.43.3.10861 or newer. A box that only says 1.43.3 is not done; 1.43.3.10828 remains in the vulnerable range.

NAS owners are in a slower lane because some vendor app stores lag Plex’s own packages. The September notice told those users to sideload the build from Plex if the catalog was stale. Docker users have to pull a new image. Automatic updates only help if they are actually on.

Plex Paid $500 and Shipped a Fix

Main reported the bugs to security@plex.tv on July 27, 2026. Plex acknowledged the report on August 4 and paid a $500 bounty the same day, which is also when Main says the vendor confirmed the issues. The first fixed Media Server build is 1.43.3.10861. Plex Desktop 1.115.0 was part of the same security round.

On October 16 he published the write-up and public Plex2Shell proof-of-concept code. The honeypot saw that code in the wild the next day, 74 days after the August 4 acknowledgment.

Unauthenticated RCE chain in Plex:

$500 bounty

Writeup: https://t.co/mpFPDLCPde
PoC: https://t.co/cOli9jBryw

Patch your servers! pic.twitter.com/GUufC4wnuf

— ZM (@zm_0x) October 16, 2026

HOW PLEX2SHELL WENT PUBLIC

1. July 27, 2026: Zach Main reports the chain to Plex.
2. August 4, 2026: Plex acknowledges the bugs, pays a $500 bounty, and treats 1.43.3.10861 as the first fixed build.
3. September 1, 2026: Plex posts a public advisory for 1.43.2 and earlier, emails owners, and asks everyone to update as soon as possible, with CVEs still pending.
4. September 23, 2026: CVE-2026-96652, CVE-2026-96654, CVE-2026-96655, and CVE-2026-96656 are assigned.
5. October 16, 2026: Main publishes the write-up and proof-of-concept.
6. October 17, 2026: The honeypot records live exploitation and the miner-plus-proxy payloads.

The September 1 note named version 1.43.3 in headline language. The later CVE table on that same thread names 1.43.3.10861 as the first build that is not affected, which is why a server that merely shows 1.43.3 under Settings, General still needs the full build number checked.

What Plex Wants Owners to Check

Plex’s updated forum post says these vulnerabilities are being actively and widely exploited, that a public proof of concept landed on October 16, and that compromised servers have been used to run cryptocurrency miners and proxy software which routes other people’s traffic through the victim’s internet connection. If the copy is older than 1.43.3.10861 and reachable from the internet, Plex’s instruction is to assume it may be compromised, then update, inspect, and if needed rebuild.

If your server is older than 1.43.3.10861 and reachable from the internet, assume it may be compromised.

Plex, forum security update

The original September security update for server owners already told people on Windows, macOS, Linux, Docker, NAS kits, and Shield how to pull a current package, including manual installs when a vendor store is behind. The October addendum is about treating a late patch as incident response, not a routine upgrade.

SIGNS PLEX SAYS TO LOOK FOR

• Strange children: Processes started by Plex Media Server that you do not recognize, especially names like myawesomeproxy, mylovelyminer, or x12345.
• Codec junk: Unfamiliar.so or.dll files in the Plex Codecs folder, which is where the chain writes its library.
• Odd traffic: Outbound connections to proxystream.st, or high CPU while nothing is playing.
• Prefs you did not set: Transcoder options in Preferences.xml that you never typed, left over from dump-yuv style abuse.
• Account hygiene: Sign out of all devices from Plex account settings and change the Plex password if you cannot rule out a hit.

Plex also says to turn off Remote Access under Settings if you do not need it, and to avoid forwarding port 32400 unless you have a reason. A self-hosted library on hardware you own does not close this hole while that port is open to the world.

Killing the Miner Leaves the Library

Stopping x12345 or mylovelyminer is not a cleanup. The useful implant is the unsigned library in Codecs, and Plex will load it again the next time a client asks for a transcode. That is why a CPU spike that “went away” after a reboot can come back the first time someone hits play on a phone.

The payload sits in Plex’s Codecs folder and runs again every time something transcodes, so killing the miner doesn’t fix it.

Nick Percoco, chief security officer at Kraken, on X

Plex’s own recovery steps go further than a process kill. Rebuild from a clean install rather than reuse the old data directory. At minimum, empty the Codecs folder and read Preferences.xml. Treat anything the Plex service account could reach as exposed, including mounted shares and credentials on the same machine or VM.

The August build closed the chain. The October PoC taught every scanner how to walk it. Owners who left 32400 on the internet past 1.43.3.10861 are not only mining for someone else. They are lending a home address to whoever is buying exits on the other side of myawesomeproxy.