DEV Community

StarkMan
StarkMan

Posted on

Plex Media Server: four flaws, one unauthenticated path to code execution

#vulnerability #plexmediaserver #cve202696654 #remotecodeexecution

Plex Media Server: four flaws, one unauthenticated path to code execution

Plex Media Server 1.43.3.10861 and later are unaffected by a chain of four vulnerabilities that Plex says has already been exploited widely. The chain starts with a request that needs no valid token, moves through internal service calls, and ends with a file write the server executes on its next start. Each CVE was scored separately and two of them carry modest scores. What makes them dangerous is the order in which they can be used.

The four fixes in 1.43.3.10861

Plex published a security notice covering versions up to 1.43.2 and later appended the CVE detail to the same thread. The notice names CVE-2026-96652, CVE-2026-96654, CVE-2026-96655 and CVE-2026-96656, and states that chained together they let an unauthenticated remote attacker run code with the privileges of the Plex Media Server process. The fixed build is 1.43.3.10861. Plex Desktop 1.115.0 shipped in the same release round.

NVD holds separate records for the four identifiers, all published 2026-09-23. Their scores from a secondary CVSS source are 4.3 for the two SSRF issues, 6.5 for the URL handling flaw in searchOne, and 7.2 for the arbitrary file write. CISA added all four to the Known Exploited Vulnerabilities catalog on 2026-10-20, with remediation deadlines of 2026-10-23 for CVE-2026-96656 and CVE-2026-96654 and 2026-11-03 for CVE-2026-96652 and CVE-2026-96655.

Step one: an unauthenticated SSRF in the player timeline

CVE-2026-96652 concerns /player/timeline. Its NVD record says the endpoint accepts a full URL in the protocol parameter and that a caller can supply any X-Plex-Token value rather than a valid one, after which the server issues a POST to the destination the caller chose. Plex describes the same issue as an unauthenticated server-side request forgery in the player timeline endpoint.

An SSRF that accepts junk credentials is a useful first step because it lets an attacker make the server reach destinations the attacker cannot reach directly. On a typical deployment the Plex process can talk to loopback services, other hosts on the LAN and cloud metadata endpoints.

Step two: plugin calls over the loopback interface

CVE-2026-96654 converts that request primitive into access to internal logic. NVD describes incorrect neutralization of URL values in searchOne, which allows an attacker to call other plugins' functions and supply their own parameters. Plex summarizes the impact as access to internal agent functions over the loopback interface, which matches how Plex agents listen locally: reachable from the server process, not from the internet.

The score here is 6.5 on CVSS 3.1, medium. Read alone, the record suggests parameter tampering with limited consequences. Read after step one, it means an unauthenticated request can drive internal agent calls whose arguments the attacker controls.

Step three: the owner's admin token

CVE-2026-96655 involves /video/:/transcode/universal, where the path parameter lets an authenticated user request arbitrary internal or external addresses. Plex describes the effect as disclosure of the server owner's admin token, which is a larger outcome than the SSRF wording in the NVD record suggests. An owner token unlocks administrative surfaces: library settings, user management, remote access configuration and the transcoder preferences used in the next step.

Step four: a file write the server executes

CVE-2026-96656 is the highest scored of the four at 7.2 and the only one CISA marks for forensic triage. NVD states that the TranscoderH264Options preference is appended verbatim to x264's option string on every transcode, that an admin user can therefore write arbitrary files, and that at startup all .so files are run without signature, execute bit or symbol checks. Plex describes the flaw as an arbitrary file write to the Codecs directory through transcoder preferences.

With the token from step three, this becomes remote code execution. Write a shared object into the directory the service loads from, then wait for or force a restart, and the payload runs as the Plex service account.

What the exploitation reports add

Plex states that a public proof of concept appeared on 2026-10-16 and that attacks against unpatched internet-facing servers have been widespread since. Compromised hosts were used to mine cryptocurrency and to run proxy software that routes other people's traffic through the victim's connection. Plex's guidance for any server older than 1.43.3.10861 that was reachable from the internet is to assume compromise.

Exposure as measured by ZoomEye

A ZoomEye query for app="Plex Media Server" returned 507,974 matching assets when this article was prepared. The CVE-specific query vul.cve="CVE-2026-96654" returned 0. The larger figure counts product assets on the internet, not confirmed vulnerable instances, and the zero on the CVE index shows how little CVE-indexed inventory exists for a chain this recent.

Fix and verification

Update to 1.43.3.10861 or newer and confirm the version in Plex Web under Settings, then General. Remote access that is not needed should be off, and forwarding port 32400 directly should be avoided unless it is required.

For hosts that may already be compromised, Plex recommends a clean rebuild rather than reuse of the old data directory, deletion of everything in the Codecs folder, and a check of Preferences.xml for transcoder options nobody set. Sign out all devices and change the Plex password. Anything the service account can reach, including mounted shares and stored credentials, should be treated as exposed.

Watch for unrecognized processes started by Plex Media Server, unfamiliar .so or .dll files in the Codecs folder, outbound connections to proxystream.st, and sustained CPU load while nothing is playing.

References

Top comments (0)