# Plex: four linked flaws turn a URL into code execution

> Plex confirms active exploitation of four related flaws. We trace the SSRF, loopback access, admin token disclosure and file write that lead to RCE.

Published: 2026-11-05  
Canonical: https://rootzero.eu/en/research/plex-ssrf-token-file-write-rce-2026/

**Corrected version available September 1, 2026; details and exploitation confirmed on October 19.** Plex describes an unusual chain of **four** vulnerabilities allowing a remote attacker without authentication to execute code with the privileges of the Plex Media Server process. Its [official advisory](https://forums.plex.tv/t/important-security-update-for-plex-media-server-v1-43-2-and-earlier/942319/) names CVE-2026-96652, -96654, -96655 and -96656, indicates that a public PoC appeared on October 16 and confirms active and widespread exploitation. The value of this story is in the successive boundaries crossed, not in a so-called “single root fault”.

## The server as the attacker's proxy

The first defect, **CVE-2026-96652**, is SSRF without authentication in the player timeline endpoint. An SSRF allows an outside actor to ask the server to produce a network request to a destination that it should not be able to reach itself. The distinction is important: getting a response from the Plex server does not yet mean reading any file or running a program. The primitive provides a **network starting point from inside** the machine.

The second defect, **CVE-2026-96654**, concerns internal agent functions accessible through the loopback interface. Normally, `127.0.0.1` is a convenient boundary: only local processes can talk there. An SSRF can break this assumption if the application agrees to relay requests to itself. The combination of the two flaws transforms a “local only” function into functionality that the remote attacker can reach indirectly.

## From internal function to administrator rights

The third element, **CVE-2026-96655**, discloses the server owner's administrator token. The token is a capability: anyone who presents it can perform operations that the system normally reserves for the owner, as long as the server accepts it. The attack chain does not “guess” the password; it retrieves a secret already recognized by the application thanks to the previous paths.

The fourth flaw, **CVE-2026-96656**, allows arbitrary file writing to the `Codecs` directory via transcoder preferences. A write becomes particularly dangerous in a location whose contents are then loaded as code or used by a privileged process. Plex claims that all four issues, combined, result in code executing with the rights of the **Plex Media Server process**. This does not automatically mean `root` or system administrator: the account under which Plex runs and the permissions of the installation determine the further scope.

The causal diagram is therefore: public HTTP entry → internal request caused by the server → function normally limited to loopback → owner token → write to `Codecs` → code executed by Plex. Each arrow requires its own condition. An article that only shows one, or calls the SSRF “RCE” without explaining the others, obscures the reason for the actual severity.

## What the public PoC proves and what the advisory leaves open

Plex confirms the publication date of a PoC, but its [advisory](https://forums.plex.tv/t/important-security-update-for-plex-media-server-v1-43-2-and-earlier/942319/) does not provide the code or a reproducible trace of each request. The reported PoC reinforces the plausibility of replication by other actors; the claim of active exploitation comes separately from Plex. Without analyzing and executing this PoC in a controlled laboratory, it would be abusive to invent the exact parameters of the endpoint, the form of the written payload or the moment when the codec is loaded. The mechanism above only takes the primitives and the result that Plex publishes.

To search for this chain class in an authorized review, we map unauthenticated endpoints that make outbound requests, then test their destination rules against loopback, private addresses, and redirects. We then identify internal functions protected only by network location and follow any route that exposes a token. Finally, a review of write operations asks whether a target directory can influence code loaded later. The useful test is not four independent scanners: it is the verification of **transitions between privileges**.

## Response and teaching

Plex sets the threshold at **1.43.3.10861** for Media Server; its initial message advised NAS users to manually install the package if their catalog did not yet offer the update. The inventory must therefore read the version of the binary actually launched, as well as the presence of an update notification. On an exposed server before correction, it is also necessary to examine abnormal accesses, active tokens and codec directory files; applying the patch does not necessarily remove the effects of a past intrusion.

This case shows why "accessible only locally" is not a sufficient barrier when another component can be persuaded to speak locally on behalf of an attacker. The defense depends as much on the validation of destinations as on the specific authorization of internal functions and the protection of the administrator token.

**Primary source:** [Plex security announcement and October 19 update](https://forums.plex.tv/t/important-security-update-for-plex-media-server-v1-43-2-and-earlier/942319/).