Threat intelligence, Threat Research

Plex2Shell: Plex Media Server Exploit Chain SSRF to Arbitrary Code Execution

by Dhiren Vaghela

Plex2Shell: Plex Media Server
(CVE-2026-96652, CVE-2026-96654,
CVE-2026-96655, CVE-2026-96656)

OVERVIEW

The SonicWall Capture Labs threat research team became aware of Plex2Shell, a chain of critical Plex Media Server vulnerabilities tracked as CVE-2026-96652, CVE-2026-96654, CVE-2026-96655 and CVE-2026-96656, assessed their impact, and developed mitigation measures. The flaws are in the Plex Media Server backend. The initial Server-Side Request Forgery (SSRF) requires no authentication, but chaining it to the file write and shell stages requires an authenticated token. Plex2Shell combines SSRF (CWE-918) with Improper Neutralization of Encoded URI Schemes in a Web Page (CWE-84) and External Control of File Name or Path (CWE-73). The CVSS score for each CVE is listed below. Although the individual flaws range from medium to high severity, the complete exploit chain has a CVSS score of 9.8, giving it a standard place in CISA-KEV. Internet exposure of a vulnerable Plex Media Server is a key requirement for exploitation.

Vulnerabilities:

CVE-2026-96652 – CVSS 8.6 – SSRF

CVE-2026-96654 – CVSS 6.9 – URI injection

CVE-2026-96655 – CVSS 5.3 – arbitrary-host SSRF

CVE-2026-96656 – CVSS 5.3 – arbitrary file write

TECHNICAL OVERVIEW

Plex Media Server is a free software application that lets users organize, store, and stream their personal collections of movies, TV shows, music, and photos from a central device to almost any screen. It acts as a private, self-hosted alternative to Netflix or Spotify: instead of paying for cloud storage or streaming subscriptions, users keep their media on their own hardware and use Plex to access it anywhere.

The SSRF flaw is in the backend server, which fails to properly sanitize or validate the protocol parameter. It accepts a full, structured URL (e.g., http://attacker-controlled-site.com) inside this parameter rather than enforcing a strict protocol scheme identifier (e.g., http or https). An attacker can provide any value for X-Plex-Token. The server processes the request anyway and constructs an outgoing HTTP POST request using the attacker-supplied URL structure, resulting in an unauthenticated SSRF.

Figure_1_Plex2shell-Technical_Overview.png
Figure 1: Plex2Shell Technical Overview

The root cause of Plex2Shell is not a single software bug but a critical exploit chain of four distinct vulnerabilities in Plex Media Server. By chaining these flaws together, an unauthenticated remote attacker can escalate access from a simple public API request into full Remote Code Execution on the host machine.

The following breakdown shows how the root causes in each phase of the exploit chain culminate in full system compromise:

Phase 1: Unauthenticated Internal Access (The Gateway)

  • Root Cause Components: CVE-2026-96652 and CVE-2026-96655 (SSRF)
  • Vulnerable Endpoint: /player/timeline
  • The Flaw: The Plex server fails to validate the X-Plex-Token parameter on certain endpoint requests (like /player/timeline), accepting any text string instead of a valid token. Simultaneously, it fails to sanitize URL fields like the protocol parameter.
  • The Impact: An unauthenticated external attacker can force the Plex server to issue HTTP requests to itself over the loopback address (127.0.0.1). Because Plex blindly trusts local traffic, this SSRF bypasses authentication entirely. The API routine uses native string concatenation to construct outbound player sync actions. Instead of enforcing a strict schema configuration (e.g., std::string target = protocol + "://" + ip + ":" + port;), it processes the variable directly as shown in Figure 2.
Figure_2_CVE-2026-96652_–_Plex_Media_Server_SSRF.png
Figure 2: CVE-2026-96652 – Plex Media Server SSRF

Phase 2: Administrative Token Leakage

  • Root Cause Component: CVE-2026-96654 (Improper Handling of Encoded URIs / Injection)
  • Vulnerable Endpoint: /system/services/searchOne or structural component plugins.
  • The Flaw: Plex handles internal administrative variables and preferences poorly when processed via injected URL sequences.
  • The Impact: Plex's plugin ecosystem mishandles nested URL encoding. The endpoint allows an attacker to insert specialized internal request routes. By passing an improperly neutralized, custom-encoded internal URI scheme, the attacker escapes the intended plugin box. They trigger other internal core plugins, changing values or overriding environment layouts to parse the local configuration databases and dump the highly privileged Plex owner token. Further, the forged call targets GetResultFromNetwork with a URL such as http://127.0.0.1.<attacker>.sslip.io/...: the server sees the "127.0.0.1" prefix, attaches the owner token, and then DNS resolves the hostname to the attacker's IP, as shown in Figure 3.
Figure_3_CVE-2026-96654_–_Plex_Media_Server_URI_Improper_Neutralization.jpg
Figure 3: CVE-2026-96654 – Plex Media Server URI Improper Neutralization

Phase 3: Malicious File Write

  • Root Cause Component: CVE-2026-96656 (External Control of File Name or Path / Path Traversal)
  • Vulnerable Endpoint: /video/:/transcode/universal
  • The Flaw: Plex Media Server dynamically downloads and caches codec packages (like H.264 decoders) to process media. The component handling the file path and download destination for these codec components does not restrict file path generation or validate the structural integrity of the downloaded file. The endpoint allows an authenticated user (now armed with the stolen admin token) to define path parameters representing target files or external locations for a stream extraction. The input parameter routing logic accepts arbitrary network paths to remote source locations instead of strictly limiting playback fetch pipelines to native storage volumes.
  • The Impact: With the stolen admin token, the attacker forces the server to download a payload from an attacker-controlled repository. Through path manipulation, they drop a malicious pre-compiled shared library module (.so on Linux or .dll on Windows) directly into the server's active Codecs directory, overwriting or standing in as a legitimate media codec as shown in Figure 4.
Figure_4_CVE-2026-96656_–_Building_and_Delivering_Payload_for_Plex2Shell.jpg
Figure 4: CVE-2026-96656 – Building and Delivering Payload for Plex2Shell

Phase 4: Code Execution (The Shell)

  • Root Cause Component: Insecure Binary Loading
  • The Flaw: When a stream transaction initializes, Plex dynamically loads the libraries in its Codecs directory into memory using calls such as dlopen() or LoadLibrary(). It executes the initialization routines of those binary components immediately upon load without checking cryptographic signatures.
  • The Impact: The attacker requests a transcoder operation (such as loading a carrier video snippet). Plex tries to parse the video, opens the newly replaced "codec" file, and immediately executes the attacker's payload. This instantiates a reverse shell (Plex2Shell) running with the permissions of the Plex user account. The download routine uses an unsafe file-path constructor. An attacker uses path traversal (../../) or configuration hijacking (Preferences.xml injections like altering TranscoderH264Options) to force Plex to save a binary payload straight into the server's working runtime directory.
Figure_5_CVE-2026-96656_–_Arbitrary_Code_Execution.png
Figure 5: CVE-2026-96656 – Arbitrary Code Execution

TRIGGERING THE VULNERABILITY

The following steps trigger the SSRF that starts the Plex2Shell chain:

STEP 1: ENDPOINT TARGETING

The attacker locates a vulnerable, internet-facing Plex Media Server listening on port 32400. The attacker then sends an HTTP POST request to the /player/timeline API endpoint.

STEP 2: AUTHENTICATION BYPASS

Normally, Plex endpoints validate incoming requests using a specific security header (X-Plex-Token). However, this endpoint logic contains a verification failure: it accepts any string, even a randomly generated one, as the value of X-Plex-Token. The header must be present, but its value can be anything. This allows an unauthenticated attacker to pass the initial authentication check.

STEP 3: MALICIOUS PARAMETER INJECTION

Inside the payload or URI parameters of the POST request, the attacker specifies the configuration for a target player. They manipulate the protocol parameter. Instead of providing a standard protocol indicator like http, they inject a fully qualified, malicious URL pointing either back to the server itself (loopback) or to an external destination.

STEP 4: VULNERABLE STRING CONCATENATION

The server-side application processes the payload. Because it lacks validation or input sanitization on the protocol string, it blindly concatenates the attacker's full URL structure to build the internal outbound HTTP request.

STEP 5: SSRF EXECUTION

The Plex server initiates a backend outbound connection dictated by the attacker's string. This forces the server to act as a proxy, letting the attacker relay requests to hidden internal services or access local administrative paths on the host. It also starts the rest of the Plex2Shell exploit sequence.

Figure_6_Triggering_the_Plex2Shell_Vulnerability.png
Figure 6: Triggering the Plex2Shell Vulnerability

EXPLOITATION

Exploitation of Plex2Shell has two parts. Exploiting the SSRF requires no credentials and no special tooling, only HTTP access to a vulnerable Plex Media Server. An unauthenticated attacker triggers the SSRF by sending a crafted request to the /player/timeline endpoint, setting the protocol parameter to a URL under their control or to an internal service. In response, the Plex server executes an HTTP POST to that location. This allows the attacker to scan internal networks, access cloud instance metadata services, or interact with internal applications that inherently trust requests coming from the Plex host.

Figure_7_Exploit_in_Action_–_CVE-2026-96652.gif
Figure 7: Exploit in Action – CVE-2026-96652

After the SSRF, inadequate controls over file names and paths lead to the next set of flaws. By combining the admin token leak with the file write vulnerability, an attacker can achieve arbitrary code execution and a shell on the remote machine, as demonstrated in Figure 8. These flaws require a valid X-Plex-Token.

Figure_8_Exploit_in_Action_–_CVE-2026-96656.gif
Figure 8: Exploit in Action – CVE-2026-96656

SONICWALL PROTECTIONS

To ensure SonicWall customers are prepared for any exploitation that may occur due to these vulnerabilities, the following signatures have been released:

Signature IDSignature Name
IPS: 22567Plex Media Server X-Plex-Token SSRF
IPS: 22568Plex Media Server Arbitrary File Write
IPS: 22569Plex Media Server URI Improper URI Neutralization

REMEDIATION RECOMMENDATIONS

The risks posed by Plex2Shell can be mitigated or eliminated with the following measures:

  • Upgrade Plex Media Server: Move to Plex Media Server 1.43.3.10861 or later through the standard Plex update channel or download the current release from the vendor. To check the installed version, open Plex Web and go to Settings → General. The entire chain collapses if the initial SSRF and file write pathways are closed.
  • Indicators of Compromise:
    • Processes started by Plex Media Server that you don't recognize, especially names like myawesomeproxy, mylovelyminer or x12345.
    • Unfamiliar .so or .dll files in the Plex Codecs directory.
    • Outbound connections to proxystream[.]st or sustained high CPU use while nothing is playing.
  • Reverse Proxy: Place Plex Media Server behind a reverse proxy that strips or validates the protocol parameter on /player/timeline.
  • Disable Remote Access on Port 32400: If remote access is not needed, turn it off under Settings → Remote Access, and do not forward port 32400 directly.
  • Deploy IPS Signatures: Apply updated signature coverage at the perimeter and on any segment that can reach an affected web server, and keep signature sets current.

RELEVANT LINKS

Share This Article

An Article By

Dhiren Vaghela

Senior Software Development Engineer

Dhiren Vaghela has over a decade of experience in the IPS domain, with a strong focus on defensive security. His expertise lies in identifying, analyzing and mitigating vulnerabilities. Dhiren is well-versed in content-based signature writing, scanner-based alert generation and technical blog writing. By leveraging emerging technologies, he has developed numerous IPS signatures across various protocols. Known for his exceptional signature writing skills and collaborative team spirit, Dhiren is a valuable asset in the field of cybersecurity.

Related Articles

  • IBM Langflow OSS unauthenticated RCE
    Read More
  • Oracle HTTP & WebLogic Servers Proxy Plug-in Authentication Bypass
    Read More