The Plex vulnerability chain known as Plex2Shell, led by CVE-2026-96652, lets an unauthenticated attacker run code on Plex Media Server, and Plex says it is being “actively and widely exploited” since a proof of concept went public on October 16, 2026. CISA added all four CVEs to the KEV catalog on October 20, with federal deadlines of October 23 and November 3. Any server older than build 1.43.3.10861 that is reachable from the internet should be treated as possibly compromised, and that includes servers whose version string already says 1.43.3.
That last point is the trap. Plex’s own September advice told owners to get onto “1.43.3 or newer”, yet the first 1.43.3 build to reach everyone is still vulnerable. Plex is also the software that let attackers into LastPass in 2022, which is why a home media server belongs in a corporate threat model at all.
What happened
The bugs were fixed quietly in August, and nobody outside Plex knew what they were until mid-October.
- July 14, 2026: Plex Media Server 1.43.3.10828 ships to everyone, per the release notes. It is vulnerable.
- July 27: researcher Zach Main reports the chain to Plex, according to the Plex2Shell write-up.
- August 4: Plex acknowledges and pays a bounty, and 1.43.3.10861, the fixed build, ships to everyone.
- September 1: Plex’s advisory asks owners to update to “1.43.3 or newer” without naming the bugs.
- September 23: the CVEs publish on NVD alongside CISA’s CSAF advisory VA-26-266-01.
- October 16: the write-up and proof-of-concept code go public.
- October 17: a honeypot run by BoredHackerBlog records in-the-wild exploitation that drops a cryptominer and a proxy tool.
- October 19: Plex confirms wide exploitation on its forum.
- October 20: KEV listing. CVE-2026-96654 and CVE-2026-96656 are due October 23, and CVE-2026-96652 and CVE-2026-96655 are due November 3.
No single bug looks alarming on its own, which is part of why this sat unnoticed for a month. The CVSS 3.1 scores in CISA’s advisory top out at 7.2, while the researcher scores the full chain 9.8.
Which Plex Media Server versions are affected
Every CVE description says “before 1.43.3.10861”, and Plex’s October 19 post agrees that 1.43.3.10861 and later are not affected. The build number is what matters, because two public signals point the wrong way.
| Build | Released to everyone | Status |
|---|---|---|
| 1.43.2 and earlier | before July 14, 2026 | Vulnerable |
| 1.43.3.10828 | July 14, 2026 | Vulnerable, although it reads as 1.43.3 |
| 1.43.3.10861 | August 4, 2026 | Fixed |
| 1.43.5.11029 | October 20, 2026 | Fixed, current release |
The second signal is NVD itself. The CPE configuration on CVE-2026-96652 and its three siblings reads “up to (excluding) 1.43.0.10861”, which disagrees with the description text. A scanner that trusts the CPE will call anything from 1.43.0 through 1.43.3.10828 clean. So check the full four-part version under Settings, General in Plex Web, and on NAS boxes expect the app store to lag, which Plex says means installing the package manually.
How the Plex2Shell chain works
What makes this chain worth understanding is not any one flaw, it is how four small ones stack, and you only need the shape of it to defend. Main’s write-up has the full detail.
Plex trusts requests that appear to come from itself. Anything arriving on the loopback interface reaches an internal plugin API with no token, and any request the server makes to a URL starting with http://127.0.0.1 gets the owner’s admin token attached automatically. Both assumptions are reasonable in isolation and dangerous together. The first bug (CVE-2026-96652) is a server-side request forgery that makes the server send a request to itself on command, so an outside attacker can reach that trusted loopback API. The next two bugs let that forged request reach a metadata plugin and point it at an attacker-controlled host dressed up as a loopback address, which hands the owner’s admin token to the attacker. No password was ever involved.
With the owner token, the fourth bug (CVE-2026-96656) does the real damage. A transcoding preference is passed to the encoder without checking, and the encoder has a debug option that writes raw output to any file path. The attacker uses it to drop a shared library into the folder it loads codecs from, and runs every file in that folder on the next transcode, with no signature or permission check. Code then executes as the Plex service account.
The researcher built the chain with heavy use of LLMs for reconnaissance and verification while keeping every judgment call himself, which is roughly how we expect vulnerability research to look from here on. For a defender, the payoff is the part that matters. Code as that service account is only step one, because it can read whatever Plex can, which means mounted media shares and any credential on the same machine.
Why a home media server is a corporate problem
The honeypot that caught live exploitation saw a cryptominer and a proxy tool dropped on compromised servers. The miner is noise. The proxy is the part that should worry a security team. Plex boxes usually sit on home broadband, and a foothold on a residential IP is what an attacker wants for routing traffic into corporate VPNs and mailboxes that geofence by address.
This is not hypothetical. The 2022 LastPass breach reached the corporate vault through a DevOps engineer’s home computer running an unpatched Plex, where attackers exploited a three-year-old flaw to plant a keylogger. The vendor’s comment at the time was that the fix had shipped “roughly 75 versions ago.” The engineer simply never updated. The version trap here makes that failure mode worse, because an owner who did update, just not far enough, ends up exposed while believing they are safe. If your staff run Plex on machines that also hold work credentials or sit on networks you care about, this CVE is yours to track, not theirs. It is the same self-hosted-software-to-RCE pattern we saw on the n8n automation flaw, just pointed at the living room.
How to detect Plex2Shell exploitation
The honeypot captured the attack over the wire, so the clearest signal lives in whatever logs the traffic to port 32400. The forged subscription request carries a loopback URL in its protocol parameter and a sslip.io hostname in the chain, neither of which a real Plex client sends. The Sigma rule below reads a reverse proxy or Zeek http.log in front of the server. It maps to ATT&CK T1190.
Data source: access logs from the reverse proxy, WAF or Zeek http.log watching inbound traffic to Plex Media Server on TCP 32400 (Sigma webserver category)
title: Plex2Shell Loopback SSRF Subscription Request
id: 7d3c1f8a-2b64-4e51-9a0c-6f9d2c4b1e07
status: experimental
description: Detects the forged /player/timeline subscription that opens the Plex2Shell chain (CVE-2026-96652), where the protocol parameter carries a loopback URL and the chain references a sslip.io host.
references:
- https://zmain.info/blog/plex2shell
- https://www.boredhackerblog.info/2026/10/plex-vulnerabilities-being-exploited-in.html
author: MarkCyber Research
date: 2026-10-21
tags:
- attack.initial-access
- attack.t1190
- cve.2026-96652
logsource:
category: webserver
detection:
selection_path:
cs-uri-stem|contains: '/player/timeline'
selection_marker:
cs-uri-query|contains:
- 'protocol=http://127.0.0.1'
- 'protocol=http%3A%2F%2F127.0.0.1'
- '.sslip.io'
condition: selection_path and selection_marker
falsepositives:
- None expected; legitimate players never put a URL in the protocol parameter
level: highThat rule catches this PoC and close variants, but not an attacker who tunnels the exploit inside TLS your proxy does not terminate, or who swaps sslip.io for another wildcard-DNS service. Treat it as one tripwire, not the whole fence. The behavior that does not change is what runs afterward. Plex should only ever launch its own binaries out of its install directory, so a process whose parent is Plex Media Server but whose image lives elsewhere is worth an alert on its own. The second rule reads Linux process telemetry and maps to T1496.
Data source: Linux process creation events (auditd, Sysmon for Linux, or EDR), from a host running Plex Media Server
title: Unexpected Child Process Of Plex Media Server On Linux
id: 1b9e5a42-7c08-4d3f-8e21-0a6b4c9f2d55
status: experimental
description: Detects a process spawned by Plex Media Server whose executable is outside the Plex install tree, as seen when Plex2Shell exploitation runs a miner or proxy as the plex service account.
references:
- https://zmain.info/blog/plex2shell
- https://www.boredhackerblog.info/2026/10/plex-vulnerabilities-being-exploited-in.html
author: MarkCyber Research
date: 2026-10-21
tags:
- attack.execution
- attack.impact
- attack.t1496
logsource:
product: linux
category: process_creation
detection:
selection:
ParentImage|endswith: '/Plex Media Server'
filter_known:
Image|startswith:
- '/usr/lib/plexmediaserver/'
- '/tmp/pms-'
condition: selection and not filter_known
falsepositives:
- Plex transcoder and timer helpers; baseline the legitimate helper paths on your build before enabling
level: highTune filter_known to your own deployment, because the transcoder’s helper path differs between native installs, Docker images and NAS packages. Plex’s own compromise checklist names host artifacts you can hunt directly. Look for processes with names like myawesomeproxy, mylovelyminer or x12345, unfamiliar .so or .dll files in the Codecs folder, outbound connections to proxystream.st, and sustained CPU load while nothing is playing. Search back to October 16, 2026, when the PoC dropped.
Mitigation
- Update to 1.43.3.10861 or later. The current release is 1.43.5.11029. On NAS devices where the app store has not caught up, install the package manually from Plex’s downloads page rather than waiting.
- If the server was on an older build and reachable from the internet, assume compromise. Plex’s advice, which we would follow, is to rebuild from a clean install rather than reuse the old data directory, because the attacker’s code ran as the service account. At minimum, empty the Codecs folder and check
Preferences.xmlfor transcoder options you did not set. - Rotate what the box could reach. Sign out all devices from your Plex account and change the password, then treat any credential stored on the same machine or VM, and anything on mounted shares, as exposed.
- Shrink the attack surface. Turn off Remote Access under Settings if you do not use it, and avoid forwarding port 32400 directly to the internet. An exposed, unpatched media server becomes a tier-zero asset whether you meant it to or not, which is the kind of exposure our security engineering work exists to remove.
Bottom line
Check the full build number on every Plex server you or your staff run, because 1.43.3.10828 looks patched and is not. Get to 1.43.3.10861 or later, and if an older build faced the internet, rebuild it and rotate every credential it could see. Then put the two Sigma rules on your proxy and host logs and hunt back to October 16.