Plex2Shell Flaws Let Hackers Hijack Plex Servers: Patch Now

Four chained vulnerabilities in Plex Media Server, collectively nicknamed "Plex2Shell," are being actively exploited to plant cryptominers and proxy malware on unpatched servers, the Cybersecurity and Infrastructure Security Agency confirmed when it added all four CVEs to its Known Exploited Vulnerabilities (KEV) catalog on October 20, 2026. Plex fixed the flaws in Plex Media Server 1.43.3.10861 and Plex Desktop 1.115.0. If your server is still running an older build and is reachable from the internet, CISA and Plex both say you should assume it may already be compromised.

What is Plex2Shell?

Plex2Shell is the name attackers and researchers have given to a chain of four separate Plex Media Server vulnerabilities — CVE-2026-96652, CVE-2026-96654, CVE-2026-96655, and CVE-2026-96656 — that, used together, let a remote attacker read a server's admin authentication token and then write an arbitrary file to disk that Plex will execute automatically. Individually, each flaw is rated "medium" or "high" severity. Chained, Plex's own security team says the result is remote code execution with the full privileges of the Plex Media Server process, achievable by an attacker with no prior account on the target server.

Plex disclosed and patched the issues quietly on September 1, 2026, with the release of Plex Media Server 1.43.3.10861 and Plex Desktop 1.115.0. The National Vulnerability Database published technical records for all four CVEs on September 23, 2026. The situation escalated on October 16, 2026, when a working proof-of-concept exploit chain was published publicly. Plex says it began observing "active and widespread" exploitation shortly after, and updated its own forum advisory on October 19 to warn server owners directly. CISA added all four CVEs to the KEV catalog the following day, October 20, 2026, which under Binding Operational Directive 26-04 sets mandatory remediation deadlines for U.S. federal civilian agencies and signals confirmed real-world exploitation for everyone else running the software.

The four CVEs, at a glance

Each vulnerability plays a distinct role in the attack chain. The two server-side request forgery (SSRF) bugs let an attacker make the Plex server send requests it shouldn't; the improper-neutralization bug lets an attacker reach internal plugin functions; and the file-write bug is the one that ultimately hands over code execution.

CISA's catalog entries for each CVE note explicitly that it "can be chained with" the other three — language the agency uses when a single flaw's real-world risk only becomes clear in combination with related bugs, similar to how it flagged the Cisco ASA/FTD chain earlier this year. For background on how these severity numbers are calculated, see our explainer on CVE identifiers and CVSS scoring.

How the attack chain works

Plex's own forum advisory lays out the mechanics in plain terms. The server-side request forgery flaws (CVE-2026-96652 and CVE-2026-96655) abuse Plex's transcoding and player-timeline endpoints, which are designed to let the server fetch and process media on a user's behalf. By supplying a crafted "protocol" or path parameter, an attacker can redirect that internal request logic toward a destination of their choosing — including internal services the server can reach but the attacker normally couldn't, such as endpoints that hand back the server owner's authentication token.

CVE-2026-96654 compounds this by failing to properly neutralize encoded URI schemes passed to the searchOne function, which lets an attacker call into other installed plugins' functions and supply arbitrary parameters of their own — effectively widening what the SSRF primitives can reach inside the server.

The final link is CVE-2026-96656. Plex Media Server stores a transcoder setting called TranscoderH264Options, which is appended verbatim to the command-line options passed to the bundled x264 encoder on every transcode. Because the server does not validate what ends up in that option string, an attacker who has reached admin-level settings access — via the token exposure described above — can plant a file inside the Codecs directory. Plex Media Server loads every .so (or equivalent) file in that directory at startup with no signature check, no check that it's actually executable code, and no symbol validation. A planted library is simply run. That's the step that converts an authentication and request-forgery problem into full remote code execution with the privileges of the Plex Media Server process itself.

Confirmed active exploitation

This is not a theoretical chain. Plex's forum post dated October 19, 2026, states plainly that the vulnerabilities are being "actively and widely exploited," two and a half months after the patched versions first shipped and three days after a public proof-of-concept exploit went live on October 16. The next day, CISA added all four CVEs to the KEV catalog — the clearest signal the U.S. government publishes that a vulnerability is confirmed to be exploited in the wild, not merely theoretically dangerous.

Plex's advisory describes attackers using compromised, internet-facing servers to run unauthorized software, including cryptocurrency-mining processes and proxy/relay software that routes third-party traffic through the victim's connection. Plex's own guidance tells administrators to look for unrecognized processes started by the Plex Media Server service, unfamiliar shared-library files inside the Codecs folder, outbound network connections that weren't initiated by normal Plex activity, and sustained high CPU usage while nothing is actively playing or transcoding — all consistent with a cryptominer or proxy backdoor running quietly in the background.

Who is at risk

The exposure here tracks directly with how a given Plex server is configured and deployed:

• Highest risk: Any Plex Media Server below version 1.43.3.10861 with Remote Access enabled and port 32400 reachable from the open internet, whether through manual port forwarding or UPnP.
• Elevated risk: Servers on older versions that sit behind a router but have Remote Access or UPnP enabled, since Plex's own relay infrastructure and NAT traversal can still expose the transcoder endpoints the chain relies on.
• Lower risk, still worth patching: Servers kept strictly on a local network with Remote Access disabled and no port forwarding. The underlying bugs are still present and should still be fixed, since network posture can change (a router reset re-enabling UPnP, for instance) without an administrator noticing.
• Plex Desktop users: Should update to 1.115.0 or later regardless of server exposure, since Desktop is a separate affected product in Plex's advisory.

Because self-hosted media servers are frequently run on consumer hardware — NAS boxes, home PCs, small home-lab servers — without the patch-management discipline of enterprise IT, this is a case where the "who's affected" question matters as much for home users as it does for organizations. The same logic applies to any self-hosted service exposed to the internet; our guide to how a firewall works covers the basic exposure-reduction steps that apply here too.

The fix: update now

Plex has already shipped the fix. There is no workaround or configuration change that fully closes all four holes short of updating the software itself:

To update Plex Media Server: open the web app, go to Settings > General > Updates, and check for and install any available update, or download the latest installer directly from Plex's download page. For Plex Desktop, the app will prompt for an update, or you can download the current installer from plex.tv. Server owners running Plex inside a Docker container or on a NAS app store (Synology, QNAP, Unraid, etc.) should update through that platform's package manager rather than assuming an in-app update covers it, since container images are typically pinned to a specific tag.

How to tell if you've already been compromised

If your server was internet-reachable and running a version older than 1.43.3.10861 any time after the October 16 proof-of-concept release, Plex recommends actively checking for signs of compromise rather than assuming a simple update is sufficient. Specifically, look for:

• Unrecognized processes spawned by the Plex Media Server service — Plex's advisory calls out example process names seen in observed attacks, including generic miner- and proxy-style binaries.
• Unfamiliar .so or .dll files sitting in your Plex Codecs directory that you didn't install yourself.
• Outbound network connections you can't account for, particularly persistent connections that don't correspond to anything you're streaming.
• Sustained high CPU or GPU usage when no media is playing and no library scan or transcode is in progress.
• Unexpected entries in Preferences.xml related to transcoder settings that you never configured, particularly anything touching TranscoderH264Options.

If you find any of this, Plex's guidance is unambiguous: don't just delete the suspicious files and patch. Rebuild the server from a clean installation rather than reusing the existing data directory, since a sufficiently persistent attacker may have planted additional footholds beyond the original payload. At minimum, clear the Codecs folder entirely, audit Preferences.xml for anything you don't recognize, sign every device out of your Plex account, change your Plex account password, and treat any credentials or network segments the Plex service account could reach as potentially exposed.

What to do next

1. Update immediately. Install Plex Media Server 1.43.3.10861 or later, and Plex Desktop 1.115.0 or later, on every installation you run.
2. Audit your exposure. Check whether Remote Access is enabled (Settings > Remote Access) and whether your router is forwarding or has ever forwarded port 32400 to your Plex server.
3. Disable what you don't need. If you don't actively use Plex's remote-streaming feature, turn off Remote Access and remove any manual port forward for 32400. Fewer exposed endpoints means fewer paths into the SSRF chain.
4. Check for indicators of compromise using the list above, especially if your server has been internet-facing and unpatched since mid-October.
5. If you find anything suspicious, rebuild rather than clean. Reinstall from scratch, rotate your Plex password, and sign out all connected devices before bringing the server back online.
6. Keep automatic updates on going forward so future fixes for issues like this land without manual intervention.

Why this matters

Plex2Shell is a useful reminder of a pattern that keeps showing up in self-hosted software: individually "medium" severity bugs — the kind that might get deprioritized on a patch schedule — become a full remote-code-execution chain once an attacker finds the right order to combine them. CISA's KEV catalog exists precisely to cut through that prioritization problem by flagging, with government confirmation, which vulnerabilities are actually being used against real targets right now rather than sitting in a research paper. For Plex Media Server specifically — software that millions of households run on devices directly connected to home networks, often with remote access turned on for convenience — a confirmed, actively exploited remote-code-execution chain is about as serious as the threat model gets for a consumer product.

Written bySana Qureshi

Sana Qureshi runs the security and privacy desk. She reports on actively exploited vulnerabilities, vendor patches and data breaches, and covers the password managers, VPNs and authentication tools readers use to protect themselves. Her alerts cite vendor advisories, CISA and the CVE record directly.

More from Sana QureshiAll Security & Privacy coverage