The Plex Media Server vulnerability chain known as Plex2Shell is being actively exploited, and updating a server does not remove an infection that has already taken hold. Plex fixed the four flaws in build 1.43.3.10861. Attackers have installed cryptocurrency miners and proxy software on unpatched servers reachable from the internet.
Which Builds Are Safe and Which Are Not
The full build number decides it, not the version number. Several builds carry the 1.43.3 label, and the earliest of them is still vulnerable, which is the detail most often missed.
| Build | Status |
|---|---|
| 1.43.2 and earlier | Vulnerable |
| 1.43.3.10828 | Vulnerable, despite the 1.43.3 label |
| 1.43.3.10861 and later | Fixed |
The build number appears in Plex Web under Settings, then General. If the final segment is below 10861, the server still needs updating. Plex has since shipped newer releases, and any of them carries the fix.
Owners of 32-bit Windows installations have no patched build available: according to SmartScope’s version analysis, distribution for that platform ended on 31 March 2026 at 1.42.2.10156. That report is the only source we found making the point, and those users cannot resolve this by updating.
Why Updating Alone Does Not Make a Server Safe
The patch closes the door; it does not evict anyone already inside. Because attackers wrote files into the Plex Codecs directory and altered transcoder preferences, those changes survive an update, and a freshly updated server can keep running a miner or a proxy.
Plex’s advisory reflects this. Rather than stopping at “update”, it tells owners to look for signs of compromise afterwards and, where compromise cannot be ruled out, to rebuild from a clean installation instead of reusing the old data directory. Most consumer coverage of this story stops at the update step.
How to Check a Plex Server for Compromise
Plex has published the specific signs to look for. In its security advisory, the company says the vulnerabilities are “actively and widely exploited” and lists the following indicators.
- Look for unrecognised processes started by Plex Media Server. Plex names myawesomeproxy, mylovelyminer and x12345 as examples seen in the wild.
- Check the Plex Codecs folder for unfamiliar .so or .dll files that you did not install.
- Watch for outbound connections to proxystream.st, or sustained high processor use when nothing is playing.
- Open Preferences.xml and look for transcoder options you did not set yourself.
- If anything matches, or you cannot rule compromise out, rebuild from a clean installation rather than reusing the existing data directory.
Plex also advises signing out of all devices and changing the Plex account password, and treating anything the Plex service account could reach — mounted network shares and stored credentials included — as potentially exposed. Where remote access is not needed, it should be switched off under Settings, then Remote Access, and port 32400 should not be forwarded directly unless there is a reason to. Our guide to reaching Plex server settings when the menu will not open covers the same screens.
Who Cannot Rely on Automatic Updates
Desktop installations largely fixed themselves; self-hosted ones did not. The gap between the patch and the attacks fell hardest on setups where updates are manual.
- NAS devices: Plex notes that packages for platforms such as QNAP pass through vendor approval and may not appear in the device’s package manager straight away, so the package can be downloaded from Plex and installed manually.
- Docker: containers running Plex’s official image on the public or beta tag pull the newest build each time they restart, but a container pinned to a specific tag stays where it is until the tag is changed and the container recreated.
- Windows and macOS desktops: automatic updates handle it where they are enabled, and the installer on Plex’s downloads page handles it where they are not.
- NVIDIA Shield: the update arrives through pending installs in the Google Play Store.
Scan-based estimates of how many servers remain exposed vary by date and method. Reporting drawing on Shadowserver data put the figure at close to 49,000 in the days after disclosure, with roughly 25,100 in North America and 17,600 in Europe, while assessments in September had counted more than 36,000 unpatched internet-facing instances. No count of actually compromised servers has been published.
How the Four Flaws Chain Together
Individually they are modest; combined they give an unauthenticated attacker code execution with the privileges of the Plex Media Server process. Plex describes the chain as follows.
- CVE-2026-96652: an unauthenticated server-side request forgery in the player timeline endpoint, which makes the server send a request to a destination the attacker picks.
- CVE-2026-96654: access to internal agent functions over the loopback interface, allowing other plugins’ functions to be called with attacker-supplied parameters.
- CVE-2026-96655: disclosure of the server owner’s administrator token.
- CVE-2026-96656: an arbitrary file write into the Codecs directory by way of transcoder preferences, where the written file is executed when loaded.
The timeline matters as much as the mechanism. Plex published its first advisory and the fixed release on 1 September 2026, urging owners to update as soon as possible without naming the flaws. A public proof-of-concept exploit appeared on 16 October, exploitation followed within about a day, and on 19 October Plex published the CVE details and confirmed widespread attacks. The people hit were overwhelmingly those running a build that had been superseded for roughly six weeks. The pattern echoes the PaperCut server campaign in September, where the exposure also lay in unpatched self-hosted installations.
What the CISA Deadlines Cover
They bind United States federal agencies, not households. CISA added all four CVEs to its Known Exploited Vulnerabilities catalogue on 20 October 2026, setting two different deadlines under Binding Operational Directive 26-04.
| CVE | Federal remediation due date |
|---|---|
| CVE-2026-96654 and CVE-2026-96656 | 23 October 2026 |
| CVE-2026-96652 and CVE-2026-96655 | 3 November 2026 |
The catalogue entries record all four as added on 20 October and list those dates. CISA marks the known ransomware campaign use of each as “Unknown”. Home users face no deadline, but the listing is the agency’s signal that exploitation is confirmed rather than theoretical.
As of 24 October 2026, the fix remains build 1.43.3.10861 or later, exploitation is continuing against exposed servers, the first federal deadline has passed and the second falls on 3 November 2026. No attribution to a named group has been confirmed.
Frequently Asked Questions
Which Plex Version Fixes the Plex Media Server Vulnerability?
Build 1.43.3.10861 or any later release. Check the full build number in Plex Web under Settings, then General, because the earlier 1.43.3.10828 build is still vulnerable.
Is My Server at Risk if It Is Not Exposed to the Internet?
The confirmed attacks have targeted servers reachable from the internet. Plex still advises updating every installation, and recommends turning off remote access where it is not needed.
Does Updating Remove a Miner That Is Already Running?
No. Files written into the Codecs directory and changes to transcoder preferences persist through an update, which is why Plex tells owners to check for the indicators and rebuild from clean if they find any.
What Did Attackers Install on Compromised Servers?
Cryptocurrency miners and proxy software that routes other people’s internet traffic through the victim’s connection. Plex has cited process names including myawesomeproxy, mylovelyminer and x12345.
Do the CISA Deadlines Apply to Me?
Only if you run systems for a United States federal agency. The 23 October and 3 November dates come from a binding directive that covers federal networks, not private households or companies.
