Why this matters now
CISA has confirmed active exploitation of Plex2Shell — four chained flaws in Plex Media Server (CVE-2026-96652, CVE-2026-96654, CVE-2026-96655, CVE-2026-96656) that together yield unauthenticated remote code execution with the owner's admin token — and added all four to the Known Exploited Vulnerabilities catalog. Researcher boredhackerblog observed exploitation against honeypots from October 17 deploying cryptominers and proxy malware, and Plex says the flaws are being "actively and widely exploited." CISA directed federal agencies to patch or mitigate the two more severe CVEs by October 23, with the other two due by November 3. The same KEV update added CVE-2026-110936, a DLL-sideloading flaw in Siemens Software Center abused in ClickFix attacks, and CVE-2026-106931, a command-injection bug in EG Secure Solutions' SiteGuard Server Edition — but Plex2Shell is the one shipping unauthenticated RCE into home labs and small offices right now.
The fix (1.43.3.10861) shipped August 3 — so any internet-reachable server still on an older build has had a known-exploitable chain for nearly three months. That gap is the real story. Media servers are rarely in the patch management program: they run quietly on a home PC, a repurposed office box, or a NAS-adjacent VM, often with port forwarding left on "temporarily." Attackers know this. The exploit chain is unauthenticated, so the hunter's first question isn't "were we breached?" — it's "do we have a Plex Media Server that was reachable from the internet on a build older than 1.43.3.10861 at any point since mid-October?"
MITRE ATT&CK frames the attack as T1190 (Exploit Public-Facing Application) for the initial access, with the observed payloads mapping to T1496 (Resource Hijacking) for the cryptominers and T1090 (Proxy) for the proxy malware. Plex's own guidance tells you exactly what to check: unfamiliar processes, unexpected Codecs files, odd outbound connections, and unexplained CPU spikes — and to treat mounted shares and stored credentials on a possibly-compromised box as exposed.
How the exploitation works
The four flaws chain together into one outcome: an unauthenticated remote attacker who can reach the Plex Media Server port (32400 by default) ends up executing commands with the owner's admin token. No credentials, no phishing, no second stage needed to get the foothold — just a reachable server on a vulnerable build. That's the full initial-access story, and it's why this belongs in the KEV catalog rather than the long tail of "someday" CVEs.
Once in, the observed post-exploitation is commodity but effective. Honeypot telemetry showed cryptominers — the quietest way to monetize a foothold, visible mostly as sustained unexplained CPU load on a box whose job is transcoding video — and proxy malware, which turns your media server into someone else's egress node and laundering relay. From there the box is a pivot point: Plex Media Server on Windows runs as a regular user account with access to mounted shares, and the server holds library metadata, account tokens, and often a trove of stored credentials. Plex's warning is blunt for a reason: assume anything the server could touch is touched.
The detection problem is that Plex is a legitimate application doing legitimate odd things — it transcodes video, opens many outbound connections, and updates its own codecs. You can't alert on "Plex used CPU" or "Plex talked to the internet." The hunt has to discriminate: version inventory to find vulnerable builds, process-tree anomalies to catch the exploit landing, filesystem changes in the codec directories to catch persistence or dropped tools, and network anomalies to catch the miner's pool traffic and the proxy's egress.
The KQL hunts
Hunt 1 — Find vulnerable Plex builds in the fleet
Start with exposure, not exploitation. Any build below 1.43.3.10861 was a known-exploitable target for roughly three months.
// Hunt 1: Plex Media Server inventory with vulnerable versions
DeviceTvmSoftwareInventory
| where SoftwareName contains "Plex Media Server"
| extend Build = extract(@"(\d+\.\d+\.\d+\.\d+)", 1, SoftwareVersion)
| extend IsVulnerable = Build < "1.43.3.10861"
| project Timestamp, DeviceName, SoftwareName, SoftwareVersion, IsVulnerable
| order by IsVulnerable desc, DeviceName ascHunt 2 — Plex processes spawning unexpected children
A media server has no business spawning shells, downloaders, or interpreters. On Windows, Plex runs as "Plex Media Server.exe" (with helpers like the Plex Tuner Service). The exploit chain lands RCE inside that process tree — so children of Plex processes are the highest-signal detection in this hunt.
// Hunt 2: unexpected child processes of Plex Media Server
let PlexProcs = dynamic(["Plex Media Server.exe", "Plex Tuner Service.exe", "PlexScriptHost.exe", "Plex Media Scanner.exe"]);
DeviceProcessEvents
| where InitiatingProcessFileName in (PlexProcs) or InitiatingProcessFileName startswith "Plex"
| where not(FileName in~ ("conhost.exe"))
| project Timestamp, DeviceName, InitiatingProcessFileName, FileName, ProcessCommandLine, AccountName
| order by Timestamp descHunt 3 — New or unexpected files in Plex codec and plug-in directories
Plex ships codecs to "%LOCALAPPDATA%\Plex Media Server\Codecs" and plug-ins under its data directories. Attackers observed dropping miner binaries or tooling nearby. Legitimate codec updates are infrequent — so file creations in these paths are rare enough to review individually.
// Hunt 3: file creations in Plex codec/plug-in directories
DeviceFileEvents
| where FolderPath contains @"\Plex Media Server\Codecs" or FolderPath contains @"\Plex Media Server\Plug-ins"
| where ActionType == "FileCreated"
| project Timestamp, DeviceName, FolderPath, FileName, InitiatingProcessFileName, InitiatingProcessCommandLine
| order by Timestamp descHunt 4 — Plex processes making odd outbound connections
Catch the payload, not the exploit: cryptominer pool traffic and proxy egress originate from the compromised server. Baseline normal Plex egress (plex.tv, CDN hosts for metadata and updates) and look at everything else, especially sustained connections to non-CDN IPs and high ports.
// Hunt 4: outbound network connections initiated by Plex processes
DeviceNetworkEvents
| where InitiatingProcessFileName startswith "Plex"
| summarize FirstSeen = min(Timestamp), LastSeen = max(Timestamp), ConnectionCount = count(), DstPorts = make_set(RemotePort), IPs = make_set(RemoteIP) by DeviceName, InitiatingProcessFileName, RemoteUrl
| order by ConnectionCount descSplunk equivalents
SPL 1 — Process creations parented by Plex (Sysmon EventCode 1)
index=sysmon EventCode=1 ParentImage="*\\Plex Media Server.exe" OR ParentImage="*Plex*"
| table _time, Computer, ParentImage, Image, CommandLine, User
| where NOT Image IN ("*\\conhost.exe")
SPL 2 — File creations in Plex codec/plug-in paths (Sysmon EventCode 11)
index=sysmon EventCode=11 TargetFilename="*Plex Media Server\\Codecs\\*" OR TargetFilename="*Plex Media Server\\Plug-ins\\*"
| table _time, Computer, TargetFilename, Image, User
SPL 3 — Network connections from Plex processes (Sysmon EventCode 3)
index=sysmon EventCode=3 Image="*Plex*"
| stats earliest(_time) as FirstSeen, latest(_time) as LastSeen, count as ConnCount, values(DestinationIp) as IPs, values(DestinationPort) as Ports by Computer, Image, DestinationHostname
| sort - ConnCountTriage: what to do when a hunt hits
Scope before you react. A vulnerable build (Hunt 1) is exposure, not compromise — pull the server's internet exposure first: is port 32400 forwarded or reachable from outside? Any Plex server on a build older than 1.43.3.10861 that was internet-reachable at any point since mid-October should be treated as potentially compromised, per Plex's own guidance. Child processes of Plex (Hunt 2) are a high-confidence compromise signal: isolate the host, capture memory and the Plex logs before remediation destroys them, and identify the initial payload — miner binary, proxy config, or dropped tools.
File hits (Hunt 3) need context: check whether the file appeared during a Plex version update or at an odd hour; submit unknown binaries for sandbox analysis. Network hits (Hunt 4) need baselining: Plex talks to plex.tv and CDN infrastructure constantly, so build a per-site allowlist and investigate sustained connections to non-CDN destinations, especially on mining-pool ports or with long-lived sessions. Across all hits, pull the timeline together — exploitation, payload drop, and first miner egress usually compress into hours.
Remediation and hardening
Patch Plex Media Server to 1.43.3.10861 or later immediately on every host you find. If a server was internet-reachable on a vulnerable build since mid-October, treat it as compromised: wipe and rebuild from a known-good image rather than patching in place, rotate any credentials or secrets stored on or accessible to the box, and treat mounted shares as exposed — check them for dropped files and review their access logs. Remove port-forwarding rules and firewall exceptions that exposed port 32400 unless the remote-access use case is genuinely required; if it is, require VPN for access and keep the server patched on a schedule.
Longer term, bring media servers into the patch program. Plex runs on unmanaged PCs in small offices and on home networks that touch corporate data — it should show up in your software inventory (Hunt 1, run monthly) and in your external attack-surface monitoring, not be discovered for the first time during incident response. The three-month gap between the August fix and the October KEV addition is the window attackers owned; the only reliable way to close that window is to patch quietly before the chain goes public.
