The vendor graded a single rivet as 'cosmetic damage' while the whole bridge is collapsing into the river
CVE-2026-96655 is a server-side request forgery in the Plex Media Server /video/:/transcode/universal endpoint. An authenticated user can supply an arbitrary URL in the path parameter and the server will fetch it — internal hosts, loopback, cloud metadata endpoints, whatever. Affects all Plex Media Server versions before 1.43.3.10861 (vulnerable code present since at least the 1.40.x line). The vendor patched it in the 1.43.3 release shipped in late August 2026 and publicly disclosed it on September 23. In isolation, it reads like a low-impact authenticated SSRF — confidentiality-low, no integrity or availability impact, CVSS 4.3.
The vendor severity is dangerously misleading. CVE-2026-96655 is step 3 in the Plex2Shell chain (CVE-2026-96652 → 96654 → 96655 → 96656), a four-bug sequence that turns an unauthenticated network packet into full remote code execution running as the Plex service user. The chain was publicly weaponized on October 16 by researcher Zach Main (code-zm/plex2shell on GitHub), and honeypots recorded in-the-wild exploitation *the next day*. Attackers are dropping XMRig cryptominers and residential-proxy implants on compromised servers. Shadowserver counts ~49,000 still-vulnerable instances exposed to the internet. Rating this CVE MEDIUM 4.3 is like rating the detonator in a bomb 'low explosive yield' — technically true, operationally absurd.
4 steps from start to impact.
Unauthenticated SSRF via /player/timeline
/player/timeline/subscribe with an arbitrary URL in the protocol= parameter. The endpoint checks only that an X-Plex-Token header *exists* — it never validates the token value. The server issues a POST to the attacker-controlled URL. This is CVE-2026-96652 and requires zero credentials. The plex2shell PoC automates this step.- Network reachability to Plex port 32400
- Target running Plex < 1.43.3.10861
- Plex must be internet-facing or attacker must be on the same LAN
- ~49K servers are confirmed exposed, so this is not a high bar
vulnerable-plex. GreyNoise likely tracking port 32400 scans. Look for POST to /player/timeline/subscribe with spoofed tokens in web logs.Loopback pivot via dead auth guard + identifier injection
identifier= parameter into the searchOne function, the attacker forces the Plex backend to treat the loopback request as coming from the server owner. This steals the owner's admin token from the server's own internal response.- Successful SSRF from step 1
- Plex internal plugin API reachable on loopback
- Requires precise URL construction, but the PoC handles it automatically
- No user interaction required
plex2shell repo includes detection signatures.Owner-authed transcoder SSRF + arbitrary file write
/video/:/transcode/universal with a crafted path parameter pointing to an attacker-hosted 'media' file. The server fetches the file and, via the dump-yuv transcoder option, writes the fetched content to an attacker-controlled path on the filesystem. This converts an authenticated SSRF into an arbitrary file write as the Plex service user.- Valid owner admin token (obtained in step 2)
- Attacker serves a malicious payload over HTTP that the Plex server can reach
- Plex service user has write access to the target directory
- Requires outbound HTTP from Plex server to attacker — most Plex servers do have outbound internet
- Docker installs may limit filesystem write scope, but the Codecs directory is always writable
/video/:/transcode/universal requests with unusual path parameters. Watch for dump-yuv transcoder arguments in process command lines.Unsigned codec dlopen → code execution
dlopen() without verifying signatures. The attacker writes a malicious .so (Linux) or .dll (Windows) into the Codecs directory using step 3's file write. On the next transcode request (which the attacker triggers immediately), Plex loads and executes the attacker's code with the privileges of the Plex service process. In Docker, this is often root.- Arbitrary file write to Codecs directory (from step 3)
- Plex service triggers a transcode operation
- The attacker triggers the transcode themselves, so no waiting required
- On Docker (very common for Plex), the service runs as root
Plex Media Server spawning unexpected children (/bin/sh, curl, wget, xmrig). The plex2shell repo provides packet captures and Suricata/Sigma rules.plexinc/pms-docker image and recreate the container. Per the noisgate remediation SLA for HIGH, patch within 180 days — but given active exploitation, treat this as an emergency patch and deploy within hours..so/.dll files in this directory will detect exploitation even if the network controls fail. This does not prevent exploitation but provides rapid detection. Deploy within the noisgate mitigation SLA of 30 days.plex.tv, plex.direct, and metadata provider domains breaks the file-write step. Deploy within the noisgate mitigation SLA of 30 days.Plex Media Server spawning /bin/sh, curl, wget, python, or any unknown binary. The plex2shell GitHub repo includes Sigma detection rules. Deploy within the noisgate mitigation SLA of 30 days.- Plex authentication hardening (strong passwords, 2FA): The chain starts with CVE-2026-96652, which bypasses authentication entirely — it checks only that a token header *exists*, not that it is valid. Strong credentials do not help.
- Reverse proxy with authentication in front of Plex: The initial SSRF in step 1 targets
/player/timeline/subscribe. A reverse proxy that requires auth on all paths *would* help, but most Plex reverse proxy guides explicitly exclude player endpoints from auth to support casting devices. Verify your specific configuration before relying on this. - Plex's built-in 'Require secure connections' setting: This enforces HTTPS but does not validate token authenticity on the vulnerable endpoint. The SSRF works over HTTPS just as well as HTTP.
The supporting signals.
| In-the-Wild Exploitation | Confirmed active since October 17, 2026. Honeypot data from multiple researchers shows exploitation within ~24 hours of PoC release. Attacker IPs: 45.194.92.222, 91.92.40.202, 176.65.139.228. Payload host: 217.60.194.116. Not yet on CISA KEV. |
|---|---|
| Proof-of-Concept | Public weaponized exploit: code-zm/plex2shell by researcher Zach Main (zmain.info). Released October 16, 2026. Full Python exploit chain with Linux and Windows payloads. Detailed write-up at zmain.info/blog/plex2shell. Also indexed on Sploitus for CVE-2026-96656. |
| EPSS | 0.00222 (0.222%), 12th percentile — stale and misleading, calculated before the weaponized PoC and in-the-wild exploitation. Expect this to spike dramatically in the next EPSS update. |
| CISA KEV Status | Not listed as of October 19, 2026. Given confirmed exploitation and public PoC, KEV addition is likely imminent. |
| CVSS Vector | CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N (4.3) — this scores the SSRF in isolation. The full Plex2Shell chain scores CVSS 9.8 (AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H). The individual score is operationally meaningless without the chain context. |
| Affected Versions | All Plex Media Server versions before 1.43.3.10861. The plex2shell repo specifically identifies versions < 1.43.3.10828 as vulnerable. Present on Linux, Windows, macOS, and NAS platforms (Synology, QNAP, etc.). |
| Fixed Version | 1.43.3.10861 (released late August 2026). Plex pushed a forced update notification on September 1. Note: Plex auto-update is *opt-in* for many NAS packages, so manual patching may be required. |
| Exposure Data | Shadowserver: ~300,000 total exposed Plex instances globally. ~49,000 confirmed still running vulnerable versions as of Oct 17. US leads with ~134,800, UK ~21,300, Canada ~19,500, France/Germany ~13,600 each. |
| Disclosure Timeline | July 27: reported to Plex. August 4: confirmed + bounty awarded. Late August: patch shipped (1.43.3.10861). September 1: Plex public advisory. September 23: CVEs published. October 16: full PoC released. October 17: in-the-wild exploitation. |
| Researcher | Zach Main (GitHub: code-zm). Responsible disclosure with ~80-day patch window before PoC release. |
Sources.
- Plex2Shell PoC Repository (code-zm/plex2shell)
- SecurityWeek — Plex2Shell Exploit Chain Weaponized Hours After Disclosure
- SecurityOnline — Plex2Shell Exploited in the Wild
- BleepingComputer — Over 36,000 Exposed Plex Servers Vulnerable
- GitHub Advisory GHSA-9x88-w2p7-56vh
- CyberSecurityNews — Plex Vulnerabilities Exploited to Deploy Cryptominer
- Gizmodo — Your Plex Server Could Be Mining Crypto for Hackers
Why this verdict
- Chain context transforms severity: CVE-2026-96655 is not a standalone SSRF — it is the file-write primitive in a four-step chain that achieves unauthenticated RCE. The vendor scored each CVE individually, masking a CVSS 9.8 attack path. This CVE specifically provides the arbitrary file write that enables the final code execution step; removing it breaks the chain.
- Active exploitation confirmed: Honeypot data from multiple researchers shows the full Plex2Shell chain being used in the wild since October 17, 2026 — two days ago. Attackers are deploying XMRig cryptominers and residential-proxy software. This is not theoretical.
- Weaponized public PoC: The
code-zm/plex2shellrepository provides a turnkey Python exploit requiring only Python 3.8, ffmpeg, and gcc. The barrier to entry for an attacker is near zero. This PoC has been copied and modified by threat actors within hours. - Massive exposed attack surface: Shadowserver counts ~49,000 still-vulnerable Plex servers internet-facing. The chain requires only TCP/32400 reachability — the exact configuration most Plex users have. No authentication, no user interaction, no unusual conditions.
- Role multiplier: Plex Media Server is overwhelmingly deployed in consumer/prosumer roles — home NAS, personal media servers, hobbyist Docker stacks. In enterprise, it is shadow IT at most. The blast radius is host-level: service-user privileges (often root in Docker). It does *not* reach domain-controller, identity-provider, or supply-chain scale. However, compromised home servers on residential IPs are being weaponized as proxy nodes (the
myawesomeproxypayload), which has indirect enterprise impact when employees VPN from compromised home networks. This keeps the verdict at HIGH rather than pushing to CRITICAL.
Why not higher?
Plex Media Server is not a canonically high-value enterprise component. It does not occupy identity, PKI, hypervisor, CI/CD, backup, or network-edge roles. The blast radius of a successful chain is host-level (Plex service user on a single media server), not domain-takeover or fleet-compromise. While the chain is unauthenticated RCE with active exploitation — which would be CRITICAL on infrastructure software — Plex is consumer media software and the overwhelming majority of its ~300K exposed instances are home servers. The residential-proxy pivot is a concern but is indirect and attenuated.
Why not lower?
Active in-the-wild exploitation is confirmed as of two days ago with public weaponized tooling. The individual CVSS 4.3 is a fiction — this CVE enables arbitrary file write in a chain that achieves unauthenticated RCE. Nearly 49,000 vulnerable servers are internet-facing. The EPSS score of 0.2% predates the PoC release and is stale. Any rating below HIGH would leave defenders treating this as routine patching while attackers are actively mass-exploiting it.
Crowdsourced verification payload.
Run this script on the Plex host (or any machine that can reach the Plex server's HTTP port). Pass the server URL as the first argument. No authentication required — it queries the unauthenticated /identity endpoint. Example: bash check_plex_cve2026_96655.sh http://192.168.1.50:32400
#!/usr/bin/env bash
# check_plex_cve2026_96655.sh — Detect Plex Media Server vulnerable to CVE-2026-96655 (Plex2Shell chain)
# Usage: bash check_plex_cve2026_96655.sh <PLEX_URL>
# e.g. bash check_plex_cve2026_96655.sh http://192.168.1.50:32400
# Exit codes: 0 = PATCHED, 1 = VULNERABLE, 2 = UNKNOWN
set -euo pipefail
PLEX_URL="${1:-}"
FIXED_MAJOR=1
FIXED_MINOR=43
FIXED_PATCH=3
FIXED_BUILD=10861
if [ -z "$PLEX_URL" ]; then
echo "Usage: $0 <PLEX_URL>"
echo "Example: $0 http://192.168.1.50:32400"
exit 2
fi
# Strip trailing slash
PLEX_URL="${PLEX_URL%/}"
# Query the unauthenticated /identity endpoint
RESPONSE=$(curl -sk --max-time 10 "${PLEX_URL}/identity" 2>/dev/null) || {
echo "UNKNOWN — could not connect to ${PLEX_URL}/identity"
exit 2
}
# Extract version from XML response
VERSION=$(echo "$RESPONSE" | grep -oP 'version="[^"]+"' | head -1 | cut -d'"' -f2)
if [ -z "$VERSION" ]; then
# Try JSON format
VERSION=$(echo "$RESPONSE" | grep -oP '"version"\s*:\s*"[^"]+"' | head -1 | cut -d'"' -f4)
fi
if [ -z "$VERSION" ]; then
echo "UNKNOWN — could not parse Plex version from response"
exit 2
fi
echo "Detected Plex Media Server version: ${VERSION}"
# Parse version: format is MAJOR.MINOR.PATCH.BUILD-hash
IFS='.-' read -r V_MAJOR V_MINOR V_PATCH V_BUILD V_REST <<< "$VERSION"
# Numeric comparison
VULN=0
if [ "$V_MAJOR" -lt "$FIXED_MAJOR" ] 2>/dev/null; then
VULN=1
elif [ "$V_MAJOR" -eq "$FIXED_MAJOR" ] 2>/dev/null; then
if [ "$V_MINOR" -lt "$FIXED_MINOR" ] 2>/dev/null; then
VULN=1
elif [ "$V_MINOR" -eq "$FIXED_MINOR" ] 2>/dev/null; then
if [ "$V_PATCH" -lt "$FIXED_PATCH" ] 2>/dev/null; then
VULN=1
elif [ "$V_PATCH" -eq "$FIXED_PATCH" ] 2>/dev/null; then
if [ "${V_BUILD:-0}" -lt "$FIXED_BUILD" ] 2>/dev/null; then
VULN=1
fi
fi
fi
fi
if [ "$VULN" -eq 1 ]; then
echo "VULNERABLE — ${VERSION} is below fixed version 1.43.3.10861"
echo " CVE-2026-96655 (SSRF) and the full Plex2Shell RCE chain apply."
echo " Upgrade immediately: https://www.plex.tv/media-server-downloads/"
exit 1
else
echo "PATCHED — ${VERSION} is at or above fixed version 1.43.3.10861"
exit 0
fi