Plex2Shell: Plex Media Server RCE chain (CVE-2026-96652)

Most people run Plex Media Server as an appliance: install it, forward a port, forget it. That is exactly the shape of system Plex2Shell targets. Four flaws, none devastating alone, line up so that an attacker who can reach the server can walk from a request-forgery trick to running code as the account Plex runs under, with no valid Plex login for the first step.

The disclosure moved in stages. A researcher reported the bugs on 27 July 2026; Plex shipped the fixed build 1.43.3.10861 to everyone on 4 August and posted a vague advisory on 1 September. The four CVEs followed on 23 September, the public proof of concept on 16 October, and in-the-wild exploitation the next morning. CISA added all four to its Known Exploited Vulnerabilities catalog on 20 October.

Who is affected

One build fixes the whole chain. There is no per-CVE patch to track.

The fixed build reached the beta channel on 3 August 2026 and the public channel on 4 August. Its release notes name two relevant changes: a CompanionProxy fix (PM-5763) and a change so the TranscoderH264Options and TranscoderH264OptionsOverride preferences can no longer be set over the network (PM-5766).

Exposure depends on reach to the server. The entry-point bug accepts any X-Plex-Token value, so it needs network access to the server port (32400 by default), not a real account. Servers with a forwarded port or Remote Access on are the ones seen under attack.

How Plex2Shell works

The chain stitches four distinct weaknesses together. Each is modest; the order is what matters.

CVE-2026-96652 — SSRF in the player timeline (CWE-918)

The /player/timeline endpoint checks only that an X-Plex-Token header is present, not that it is valid. An attacker can supply a full URL in the protocol parameter and make the server POST to a destination of their choosing. This is the unauthenticated foothold.

CVE-2026-96654 — encoded URI scheme handling (CWE-84)

URL values passed in searchOne are not neutralised correctly, which lets a caller invoke other plugins' functions and supply their own parameters. This bridges the outside request into internal plugin functionality.

CVE-2026-96655 — SSRF via the transcode path (CWE-918)

A user can make the server request arbitrary internal or external addresses through the /video/:/transcode/universal path parameter. With the plugin-function access above, this is how the chain reaches loopback-only internals and, per Plex's summary, the owner's admin token.

CVE-2026-96656 — arbitrary file write that loads on start (CWE-73)

With an admin-level token, a transcoder preference can be used to write files into the Codecs directory. At startup every .so file there is loaded without signature, execute-bit or symbol checks, so a written file runs as the Plex service user. That is the code-execution endpoint of the chain.

The CISA-coordinated advisory also lists a fifth Plex bug, CVE-2026-96651 (path traversal), fixed in the same build but not added to KEV.

Is it being exploited?

Yes. All four CVEs entered CISA KEV on 20 October 2026. Plex states the flaws are being actively and widely exploited. CISA lists ransomware use as unknown.

• Public PoC: published 16 October 2026.
• In the wild: an independent honeypot recorded exploitation on the morning of 17 October, deploying an XMRig-based miner and proxy software named myawesomeproxy.
• Not confirmed: a blogger's suggested link between the proxy traffic and the "Aisuru" botnet is their hypothesis, not a confirmed attribution. No actor is named.

The KEV due dates split: CVE-2026-96654 and CVE-2026-96656 were due 23 October, CVE-2026-96652 and CVE-2026-96655 by 3 November. Patch to the single fixed build and all four are closed.

Check your exposure

Confirm the running build and whether the server is reachable from outside, then look for files that should not be in Codecs.

# Linux package install: the data directory holds Preferences and Codecs.
PLEXDIR="/var/lib/plexmediaserver/Library/Application Support/Plex Media Server"
 
# Version the server reports (also under Settings > General in the web UI).
grep -o 'version="[^"]*"' "$PLEXDIR/Preferences.xml" 2>/dev/null | head -1
 
# List native modules under Codecs; compare against a known-good server.
find "$PLEXDIR/Codecs" -name '*.so' -o -name '*.dll' 2>/dev/null
 
# Transcoder options you did not set are a red flag.
grep -o 'TranscoderH264Options[^ ]*="[^"]*"' "$PLEXDIR/Preferences.xml" 2>/dev/null

On Windows the data directory is %LOCALAPPDATA%\Plex Media Server; on macOS it is ~/Library/Application Support/Plex Media Server/. In all cases, check whether port 32400 is forwarded at your router and whether Remote Access is enabled.

Fix it

Update to 1.43.3.10861 or later and confirm the version in Settings, General. Container images need a pull and recreate, not just a restart.

If the server was internet-facing on a vulnerable build, assume it may have been reached. Plex's guidance is to rebuild from a clean install rather than reuse the old data directory; at minimum, clear the Codecs folder and remove transcoder options you did not set from Preferences.xml. Then sign out of all devices, change your Plex account password, and treat credentials and mounted shares on the same host as potentially exposed.

To cut exposure going forward, disable Remote Access if you do not use it and avoid forwarding port 32400 directly.

Detect attempts and compromise

Plex published these signals of a compromised server:

• Unfamiliar processes started by Plex, with names such as myawesomeproxy, mylovelyminer or x12345.
• Unexpected native modules — .so or .dll files you do not recognise in the Codecs folder.
• Outbound connections to proxystream.st.
• Sustained high CPU while nothing is playing.
• Transcoder options in Preferences.xml that you never configured.

If any of these fired, the attacker had code execution as the Plex service user and could read anything that user can. Rebuild rather than clean in place.

Beyond this patch

Plex2Shell is a chain, and chains are why mid-severity components deserve attention: individual scores top out at CVSS 4.0 8.6, yet the combined result is remote code execution. The durable lesson: patch appliance software on a schedule and confirm a fix with evidence, not a version string. Rokkhe's retests re-run a reproduced finding against the patched system; how a retest verifies a fix describes that evidence.