Dev.to Security 🔐 Cybersecurity 👁 0 📖 2 min read

Why any X-Plex-Token value matters in the Plex timeline SSRF

Why any X-Plex-Token value matters in the Plex timeline SSRF Most SSRF advisories stop at the request the attacker can make. The CNA record for CVE-2026-96652 adds a detail that changes how defenders should read the fl

Why any X-Plex-Token value matters in the Plex timeline SSRF

Most SSRF advisories stop at the request the attacker can make. The CNA record for CVE-2026-96652 adds a detail that changes how defenders should read the flaw: the server accepts any X-Plex-Token value on the vulnerable path. That wording moves the barrier away from token validity and towards simple reachability of one endpoint.

Vulnerability overview

The record describes Plex Media Server before 1.43.3.10861 allowing SSRF through /player/timeline, where an attacker with any X-Plex-Token value can put a full URL into the protocol parameter and force a POST to a chosen destination. CVSS v3.1 is 4.3 with AC:L, PR:L and UI:N, the weakness is CWE-918, and CVSS v4.0 is 5.3. CISA's SSVC assessment records Exploitation as none, Automatable as no and Technical Impact as partial.

Mechanism and exploitation conditions

Plex clients authenticate to the server with a token passed in a request header. The timeline endpoint uses that header and then builds an outbound request from the protocol value. When the code does not validate the value as a scheme, the request target becomes attacker-controlled. The record's phrasing about any token value suggests the endpoint checks for the presence of a header rather than verifying that the token belongs to a real account.
An attacker who can reach the endpoint therefore needs little more than network access and a header. No user has to click anything, which matches the UI:N entry in the vector, and the low privileges entry reflects a requirement that is closer to form than to identity.

Impact

The outcome is an HTTP POST issued from the Plex host. Confidentiality impact is low because the attacker learns from whatever the server returns or logs about that request, and the record lists no integrity or availability impact. The interesting cases are internal networks where a media server sits beside administration interfaces, metadata services or other appliances that filter by source address.

Affected products and scope

The scope is Plex Media Server versions below 1.43.3.10861. Servers exposed to the internet and servers used by many household members both present the endpoint, and a server that terminates a VPN for remote viewing extends the reach of the request into whichever network it can address.

Exposure context

A ZoomEye search for app="Plex Media Server" returned 507,974 matching assets at the time of writing. That figure is a product census. It says nothing about whether a given server accepts timeline requests from an untrusted address, and the CVE filter vul.cve="CVE-2026-96652" returned zero matches, so the specific vulnerable population is not visible through that field.

Remediation and mitigations

Upgrade to 1.43.3.10861 or later. Before the upgrade lands, place the server behind a reverse proxy that rejects unexpected protocol values and log outbound POST requests initiated by the Plex process so that a forged timeline request leaves a trace. After upgrading, review whether the service should accept requests from outside the local network at all.

References

  1. CVE-2026-96652 record, https://www.cve.org/CVERecord?id=CVE-2026-96652
  2. CNA record, https://cveawg.mitre.org/api/cve/CVE-2026-96652
  3. Plex release notes for 1.43.3.10861, https://forums.plex.tv/t/plex-media-server/30447/711
  4. CISA CSAF advisory, https://raw.githubusercontent.com/cisagov/CSAF/develop/csaf_files/IT/white/2026/va-26-266-01.json
📰 Read the original article on Dev.to Security

Originally published by Dev.to Security. Aggregated on AIWithGhost for educational purposes — full credit and traffic to the original publisher.