Plex has confirmed that a chain of vulnerabilities in Plex Media Server, first documented in September, is now “being actively and widely exploited.” The wording appears verbatim in a security notice the company refreshed on 19 October, and it marks the moment a quietly patched bug class turned into a live, internet-wide campaign. Chained together, the flaws let an unauthenticated remote attacker execute code with the privileges of the server process — no login, no user interaction and no presence on the local network required.
- The fix: Plex Media Server 1.43.3.10861 or later; the desktop client was corrected in version 1.115.0. The patch has existed since early August.
- The trap: build 1.43.3.10828 looks like part of the corrected series but is not. Censys counted nearly 8,000 servers running precisely that number.
- The exposure: around 324,000 Plex servers are reachable from the internet, roughly 30% of them on a vulnerable build, with 44% hosted in the United States and most sitting on residential broadband lines.
- The payload: attackers are planting an XMRig-based cryptocurrency miner and proxy software that resells the victim’s connection.
Anatomy of the Plex2Shell chain
Plex counts four flaws; the NIST National Vulnerability Database and the advisory CISA coordinated on 23 September list five, adding one the company never mentions. The anchor is CVE-2026-96656, an external control of file name and path that permits writing files loaded at startup — rated 7.2 under CVSS 3.1 and 8.6 under CVSS 4.0. The two figures are not a contradiction but two different scales, a distinction much of the coverage has blurred. The others are a pair of server-side request forgery bugs and an improper neutralisation of URI schemes that lets an attacker invoke functions belonging to other plugins. The fifth, CVE-2026-96651, is a directory traversal that allows anyone holding a valid session token to read any file the user can reach, including the Plex account token — which hands over both account and server.
Individually, several of the flaws demand privileges, in some cases administrator rights. Chained, none do. All of them carry a network vector, and the researcher who found them rates the assembled chain at CVSS 9.8. Exploitation requires reachability on TCP port 32400, which Plex’s Remote Access feature or manual port forwarding extends to the open internet; internally reachable servers stay exploitable from inside the same network.
A timeline that explains the urgency
The chronology is the real story. The flaw was reported on 27 July, acknowledged and paid for on 4 August — the same day the corrected build surfaces in Censys telemetry. A public notice followed on 1 September with no technical detail, and CVE identifiers landed on 23 September. On 16 October a detailed write-up with proof-of-concept code went live. The following morning, the first exploitation appeared on a honeypot. Plex confirmed active abuse on 19 October, and on 20 October CISA added the flaws to its Known Exploited Vulnerabilities catalogue, setting federal remediation deadlines of 23 October for two of them and 3 November for the rest, with forensic triage required for the most severe.
The patch numbers explain the rest. Around 30% of operators updated within a week of the fix; half were still vulnerable when September’s advisory went out. In the three days after the exploit chain became public, fewer than 2% of the remaining vulnerable servers were updated. None of these figures count victims — no one, Plex included, has published a number of compromised hosts. They measure exposure.
Miners, proxies and the residential IP prize
The choice of payload follows the location. A Plex server typically lives on a home connection, and residential addresses carry a reputation that attackers value. “Plex can be hosted on a residential IP, and I think threat actors would love to have a residential IP proxy,” the researcher who detected the first exploitation wrote. The proxy tooling itself is blunt about the trade-off, warning in its own terms of service that using it means accepting “the possible external use of your internet traffic.”
Plex has published indicators: unfamiliar processes spawned by the server with suggestive names, unknown .so or .dll files in the Codecs folder, outbound connections to proxystream.st, and sustained high CPU load with nothing playing. The reporting researcher cautions that his list reflects only what he observed. If compromise cannot be ruled out, Plex recommends rebuilding from a clean install without reusing the old data directory, emptying Codecs, auditing preferences, signing out of every device, rotating the password and treating everything the service account could reach as exposed.
Discovery is credited to Zach Main, who reported the flaws in July. Tellingly, the advisory is signed by the forum’s institutional account: no named executive or spokesperson is attached to any of it.
The uncomfortable lesson is not that Plex handled disclosure badly — it paid a bounty and shipped a fix in eight days. It is that self-hosted software on hundreds of thousands of home connections, NAS boxes waiting on vendor repositories and Docker containers outside any asset inventory has no reliable path to patching. The attacker never needed a new bug; ten weeks of patience and a published proof of concept were enough. This campaign carries no documented link to Plex’s September 2025 data breach or the 2022 intrusion — those were account-data thefts on company systems, while this is code running in living rooms.