---
title: "Plex’s $500 Bug Bounty Chained Four Flaws Into Unauthenticated Root"
description: "A patch sat unused on thousands of servers for two months before public exploit code turned it into a cryptomining botnet overnight"
author: "Luis Goa"
published: 2026-10-19T19:39:19Z
modified: 2026-10-20T02:10:57Z
url: https://rews.cc/a/plex-s-500-bug-bounty-chained-four-flaws-into-unauthenticate-e29dd4
language: en
tags: ["cybersecurity", "ssrf", "ai", "hacking", "security", "tech"]
publisher: "Rews (https://rews.cc)"
---

# Plex’s $500 Bug Bounty Chained Four Flaws Into Unauthenticated Root

*A patch sat unused on thousands of servers for two months before public exploit code turned it into a cryptomining botnet overnight*

By Luis Goa · October 19, 2026 · https://rews.cc/a/plex-s-500-bug-bounty-chained-four-flaws-into-unauthenticate-e29dd4

## In brief

- Plex patched a four-CVE exploit chain called Plex2Shell on August 3, 2026, after a $500 bounty payout
- Public exploit code went up October 16; in-the-wild attacks on a honeypot began the next morning, October 17
- The chain runs two SSRF bugs and a token theft to plant a fake codec file that executes with Plex’s own privileges
- Attackers dropped an XMRig cryptominer and a residential-proxy backdoor called myawesomeproxy linked to the AISURU botnet
- Shadowserver counted over 36,000 exposed vulnerable Plex servers in a September 9 scan; patch to 1.43.3.10861 or later

Plex Media Server shipped a fix for four chained vulnerabilities on August 3, 2026. The build was called 1.43.3.10861. Attackers started exploiting the unpatched version 75 days later, on October 17, one day after the researcher who found the bugs published his technical write-up and proof-of-concept code. [Shadowserver](https://www.esecurityplanet.com/news/news-plex-security-flaws-36000-servers-unpatched/) counted more than 36,000 internet-facing Plex instances still running an affected build as of its September 9 scan; Censys separately counted over 360,000 devices exposing a Plex web interface at all, a bigger number because it includes patched servers too. Nobody has published a count of how many of the 36,000 are now compromised.

The chain is tracked as four CVEs, each unremarkable on its own and each rated Medium or High, never Critical, by the National Vulnerability Database. CVE-2026-96652 is a server-side request forgery (SSRF) in the unauthenticated /player/timeline endpoint: the server accepts a client-supplied “protocol” value as the full destination URL for an outbound POST and never checks whether that destination is trusted, a flaw [SentinelOne’s vulnerability database](https://www.sentinelone.com/vulnerability-database/cve-2026-96652/) scores 5.3 out of 10. CVE-2026-96654, scored 6.5 to 6.9 depending on which CVSS version a given tracker applies, is an improper-neutralization bug in the searchOne endpoint that lets an attacker call functions belonging to other Plex plugins and pass them arbitrary parameters, including ones that return the server owner’s admin token. CVE-2026-96655, another SSRF, scored 5.3, lets a request carrying that stolen token reach the /video/:/transcode/universal endpoint and fetch an attacker-hosted file, such as a malicious ELF binary, as if it were ordinary video to transcode. CVE-2026-96656, rated 8.6 by [SentinelOne](https://www.sentinelone.com/vulnerability-database/cve-2026-96656/), is the payoff: Plex’s codec loader checks neither a library’s name, its execute permission, its digital signature nor its exported symbols before running it, so the planted ELF file executes as the Plex service account the moment the server’s transcoder touches it.

**How Plex2Shell reaches root with no login** The four chained CVEs, in exploitation order

| From | To | How |
| --- | --- | --- |
| Attacker, no credentials | SSRF via /player/timeline *(CVE-2026-96652)* |  |
| SSRF via /player/timeline *(CVE-2026-96652)* | Steal owner's admin token *(CVE-2026-96654, searchOne endpoint)* |  |
| Steal owner's admin token *(CVE-2026-96654, searchOne endpoint)* | SSRF via transcode/universal *(CVE-2026-96655, with stolen token)* | uses token |
| SSRF via transcode/universal *(CVE-2026-96655, with stolen token)* | Malicious ELF planted as codec | fetches payload |
| Malicious ELF planted as codec | Code runs as Plex service account *(CVE-2026-96656, unsigned codec load)* | transcoder loads it |

![How Plex2Shell reaches root with no login. The four chained CVEs, in exploitation order](https://rews.cc/img/fd8b77a38ef0c0dca01ffaa56614402aa9549b5a.webp)

Based on [Zach Main (zmain.info), SentinelOne vulnerability database](https://zmain.info/blog/plex2shell)

The researcher, who publishes as Zach Main and goes by “ZM,” named the chain Plex2Shell and [reported it to Plex](https://zmain.info/blog/plex2shell) on July 27, 2026. Plex acknowledged the report and paid a bug bounty of $500 on August 4, the day after the fixed build went out. Plex requested CVE identifiers, which NVD assigned on September 23. Main published the full write-up and working exploit on October 16. The $500 figure drew immediate criticism on social media, with multiple replies to his announcement asking whether he had dropped a zero: an unauthenticated path from zero credentials to arbitrary code execution on the service account is, by most bug-bounty programs’ own fee schedules, worth low five figures, not three.

## What the AI actually did

Main’s write-up frames the hunt as a four-stage loop he calls Recon, Hunt, Verify, Chain, and says he used large language models “heavily for all 4 parts.” Recon means breaking the server into components and mapping every path from user input to a dangerous sink. Hunt is a focused vulnerability search within one component. Verify means spawning a second model instance whose job is to try to disprove each candidate bug; if it can’t, the bug is probably real. Chain means searching the found primitives for the combination with the largest impact. As [Ars Technica’s Dan Goodin reported](https://arstechnica.com/security/2026/10/recently-fixed-plex-media-vulnerabilities-are-being-exploited-to-install-malware/), Main was explicit that this was not “go hack Plex” as a single prompt: it was, in his words, “hours of iterative work, dead ends, and reprioritization. All of the judgment calls on what to look for and what to prioritize were mine. The LLM speeds this process up significantly, allowing me to stay at a higher level and simply guide the process.” That is a narrower claim than the headline-friendly version circulating since: an LLM found four bugs and chained them into a 10-out-of-10 exploit. What the record actually shows is a model acting as a fast, tireless pattern-matcher and a skeptical second opinion, directed at every step by a human who already knew what a dangerous sink looks like. Whether the same loop would work without that human remains untested, because nobody has published a version where it is.

![A human hand holds a robotic hand that pinches an orange chain connected to an open padlock against a teal background.](https://rews.cc/img/50426f93985e10875965b64fd8b4133fc4d5a650.webp)

The chart shows why severity scoring missed this: CVSS rates each flaw in isolation, and none of the four crosses 8.6. Chained, they add up to unauthenticated root. The honeypot researcher who publishes as [BoredHackerBlog logged the first real attack](https://www.boredhackerblog.info/2026/10/plex-vulnerabilities-being-exploited-in.html) on the morning of October 17, writing: “As of this morning (Oct 17th), I finally saw in the wild exploitation.” The request came from IP 45.194.92.222 with the user agent Python-urllib/3.10, hitting /player/timeline/subscribe; two more source addresses, 91.92.40.202 and 176.65.139.228, followed. The payload files, named docker and x, were pulled from 217.60.194.116; x turned out to be a UPX-packed binary that unpacked into two further tools. One was xmrig, the open-source Monero miner, running under the process name mylovelyminer and reporting to a mining pool at ota.proxystream\[.\]st. The other was myawesomeproxy, which [TheHackerNews described](https://thehackernews.com/2026/10/hackers-exploit-plex2shell-flaws-to.html) as a Linux backdoor and reverse proxy that displays, on launch, the message: “Running this software on any of your devices makes you agree to the potential external use of your internet traffic.”

The proxy is the more interesting payload. A cryptominer steals compute; a residential reverse proxy steals an IP address with a clean reputation. Plex runs overwhelmingly on home connections, and corporate anti-fraud and VPN systems generally trust residential IP ranges more than data-center ones. BoredHackerBlog’s assessment, reported by [SecurityWeek](https://www.securityweek.com/plex2shell-exploit-chain-weaponized-against-plex-servers-hours-after-disclosure/), was blunt: “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.” A related subdomain, global.relay.proxystream\[.\]st, was flagged by the security firm Bitsight in August 2026 as infrastructure tied to AISURU, a DDoS and proxyware botnet, suggesting the Plex compromises are feeding an existing criminal proxy network rather than standing up a new one.

![A cream-colored house on a blue background has a thick network cable entering from the left and three dark cables extending out to the right.](https://rews.cc/img/438cd5cb233349f2eadebea1cefa372093a8f2d0.webp)

The disclosure-to-exploitation gap here, 75 days from patch to attack and then one day from public PoC to in-the-wild use, is the pattern bug bounty programs are supposed to prevent, not the pattern they’re supposed to produce. Plex patched quietly in August without describing the flaws, announced an update on September 1 without technical detail, and the specifics only became public when the researcher who found them wrote them up two and a half months later. Every day between the September 1 notice and the October 16 write-up was a day administrators had the generic instruction to update but no way to judge how urgent it was. Once the mechanism was public, the exploitation followed within hours, not weeks.

Plex Media Server versions before 1.43.3.10828 remain vulnerable; the fix shipped in 1.43.3.10861, alongside Plex Desktop 1.115.0. Administrators who have not updated should do so immediately. Beyond patching, the safest configuration keeps Plex off the open internet entirely and reachable only on the local network, which forfeits remote-access features; a reverse proxy on a non-default port instead of the default 32400 is the next-best option for anyone who needs external access. Main’s write-up and PoC remain public at zmain.info, which means the exploit code that compromised the honeypot in under 24 hours is sitting in the same place any other operator of an unpatched server can find it.

## See also

- [Plex urges immediate updates after patching multiple undisclosed security flaws](https://thehackernews.com/2026/09/plex-urges-immediate-updates-after.html) — thehackernews.com · Plex's original, detail-free September 1 advisory