Plex Media Server flaws (CVE-2026-96652 and three more) are being exploited to install miners and proxy malware

Attackers are exploiting a chain of four recently patched vulnerabilities in Plex Media Server to run code on internet-facing servers, and Plex itself now says anyone running a version older than 1.43.3.10861 that is reachable from the internet should "assume it may be compromised". Plex published the CVE details and confirmed active, widespread exploitation on 19 October 2026, three days after a researcher released a public proof of concept called Plex2Shell. Successful attacks so far install cryptocurrency miners and residential proxy software.

Key points

• Plex says four vulnerabilities fixed in Plex Media Server 1.43.3 (CVE-2026-96652, -96654, -96655 and -96656) can be chained by an unauthenticated remote attacker to run code as the Plex server process.
• A public proof of concept was released on 16 October 2026; Plex says it has since seen widespread attacks against servers that were not updated.
• Compromised servers have been used to run cryptocurrency miners and proxy software that routes other people's traffic through the victim's connection.
• Servers on 1.43.3.10861 or newer are not affected, according to Plex; the fix was first shipped on 1 September 2026.
• Plex's advice is to update, look for signs of compromise, rebuild from a clean install if in doubt, and switch off remote access if it is not needed.

What happened

On 1 September 2026 Plex announced Plex Media Server 1.43.3 and Plex Desktop 1.115.0 "to address a number of security issues", and said CVE identifiers had been requested. On 16 October the security researcher who found the bugs published a write-up and proof-of-concept code under the name Plex2Shell. His post lists the four CVEs, a report to Plex on 27 July, acknowledgement and a bounty on 4 August, and CVE assignment on 23 September.

On 19 October Plex added an update to its security thread listing the CVEs and stating the vulnerabilities "are being actively and widely exploited". Ars Technica reported the same day that a separate researcher had set up a honeypot, a simulated Plex server, and began seeing active scanning within a day of the exploit's release, followed by successful infections. The two payloads that researcher saw were a cryptominer and residential proxy software. Plex told readers to check for processes with names such as myawesomeproxy, mylovelyminer or x12345, for unfamiliar .so or .dll files in the Codecs folder, and for outbound connections to proxystream.st.

Background

Plex Media Server is software people run on a home server, NAS or cloud machine to stream their own media. It listens on port 32400 and is often exposed directly to the internet so people can watch away from home, which makes the attack surface unusually public for consumer software. That is why a bug chain that needs no login matters more here than a typical local-only flaw.

The disclosure timeline is unusual in its gaps. The fix shipped on 1 September, but the CVE details came only on 23 September (assignment) and 19 October (Plex's published list). Ars Technica says Plex fixed four vulnerabilities at the start of September and that, three weeks later, published CVE designations revealed five, one rated 8.6 out of 10. Plex's own list in its thread names four CVEs, the ones the researcher chained; we could not find the fifth in the sources we checked, so we cannot say which it is.

How it works

The researcher's write-up describes five steps. We summarise it here in our own words; it is the researcher's account of the chain, and Plex's list matches the CVEs he names.

1. Unauthenticated request forgery (CVE-2026-96652). The player timeline endpoint requires an X-Plex-Token header for requests from the internet, but checks only that the header exists, not that it is valid. Any junk value passes, and the server can then be tricked into sending a request to itself.
2. Loopback pivot (CVE-2026-96654). Plex trusts requests that come from 127.0.0.1, and its plugin-management API opens without a token for them. A forged request arriving from the server itself can therefore reach that API. A broken check meant to restrict it to registered plugins did not stop anything, according to the write-up, and an unsanitised identifier let the attacker shape the request.
3. Admin token theft (CVE-2026-96655). The server attaches the owner's admin token to outbound requests whose URL starts with http://127.0.0.1. That is a prefix match, so a hostname such as 127.0.0.1.<attacker>.sslip.io passes the check but resolves to the attacker's machine, which receives the token.
4. Payload delivery. With owner access, the attacker points the transcoder at a video file they host.
5. Arbitrary file write and code execution (CVE-2026-96656). A transcoder preference lets the output be written to a chosen path in the Codecs directory. The written file is a bit-exact copy of the input, which can be a shared library; the next transcode loads it and the code runs as the Plex service user.

Each step on its own is modest. The danger is the chain: an anonymous request from the internet ends with code running on the server. The researcher also says he used large language models heavily to find and chain the bugs, working through a loop of mapping components, hunting, having a separate agent try to disprove each finding, and chaining. He stresses that it "was not a matter of telling the LLM 'go hack Plex'" and that the judgement calls were his. Ars Technica notes that the published exploit code was the proof of concept he submitted with his bug report.

The numbers

type: bar
title: Plex Media Server vulnerability timeline, days after the researcher's report on 27 July 2026
unit: days
source: Researcher write-up (zmain.info) and Plex security thread
Plex acknowledges and pays bounty (4 Aug) | 8
Fix announced, 1.43.3 (1 Sep) | 36
CVEs assigned (23 Sep) | 58
Public proof of concept (16 Oct) | 81
Plex confirms active exploitation (19 Oct) | 84

Counting from the researcher's report, Plex announced the fix 36 days later, on 1 September, and the public proof of concept followed 45 days after that. That is the period in which servers that did not update stayed exposed to anyone who read the write-up.

Plex does not publish a count of affected or compromised servers, and neither do the sources we found, so we do not give one.

What it means

For Plex owners the instruction is short: check Settings → General for the version number, and update to 1.43.3.10861 or newer. NAS owners may find the package manager lags and need to install manually; Plex's September post has per-vendor steps. If the server is older, was reachable on port 32400, and you cannot rule out compromise, Plex recommends a clean rebuild rather than reusing the old data directory, at minimum deleting the Codecs folder and checking Preferences.xml for transcoder options you did not set. It also advises signing out all devices, changing the Plex password and treating anything the Plex service account could reach, such as mounted shares and stored credentials, as potentially exposed.

Ars Technica adds hardening ideas: restrict the server to the local network where possible, or place it behind a reverse proxy instead of exposing the default port, and use only secure Plex apps.

For defenders more broadly, two points stand out. First, residential proxy payloads are valuable because home connections look like ordinary users; one researcher quoted by Ars said attackers may want them to reach corporate VPNs and email. Second, the gap between a patch and widespread exploitation keeps shrinking when the proof of concept is public and detailed. Plex's own advice that exposed, outdated servers should be assumed compromised reflects that.

What we don't know yet

• How many servers were compromised or are still exposed; no source gives a figure.
• Whether a fifth vulnerability exists. Ars Technica reports five CVEs; Plex's published list has four.
• Whether other payloads beyond the miner and proxy software are in use. Reports so far name only those two.
• Whether Plex will say more about why CVE details took until 19 October. Ars says Plex did not immediately respond to questions.

What to watch next

Watch Plex's security thread for further updates, including indicators of compromise and any fifth CVE. Check whether your NAS vendor's package has caught up. If you run a server open to the internet, treat the next few days as the time to move it behind a reverse proxy or VPN.

Sources

• Plex forum: Important Security Update for Plex Media Server v1.43.2 and earlier (primary; updated 19 October 2026)
• zmain: Plex2Shell, unauthenticated RCE in Plex Media Server (researcher's write-up, 16 October 2026)
• Ars Technica: PSA: Patch your Plex media server before someone hacks it (19 October 2026)