CVE-2026-96652: Plex Media Server SSRF

Detection Guidance

Begin with asset and version validation. Identify every Plex Media Server instance, record its listening addresses and versions, and determine whether each server is directly exposed through a firewall, router, reverse proxy, tunnel, or remote-access service.

Review web-server, reverse-proxy, and Plex-related logs for requests to /player/timeline containing unusual protocol values. Potential indicators include:

• Full URLs where a normal media timeline request is expected
• Private or loopback addresses
• Cloud metadata addresses
• Unexpected destination ports
• Requests followed by outbound HTTP POST traffic from the Plex host
• DNS lookups for unusual internal or attacker-controlled domains

Network telemetry should be checked for outbound connections from the Plex host immediately after suspicious inbound requests. Prioritize destinations that are internal, link-local, loopback, administrative, or otherwise atypical for Plex operations.

Technical Detection Examples

A generic web or reverse-proxy search can identify likely requests without assuming a particular log format:

grep -E '(/player/timeline|protocol=)' /var/log/nginx/access.log \
  | grep -Ei 'https?%3A|https?://|127\\.0\\.0\\.1|localhost|169\\.254\\.169\\.254|10\\.|172\\.(1[6-9]|2[0-9]|3[0-1])\\.|192\\.168\\.'

For JSON logs in an Elastic-style environment, a starting query is:

url.path:"/player/timeline" AND
(
  url.query:"protocol=http*" OR
  url.query:"protocol=https*" OR
  url.query:*127.0.0.1* OR
  url.query:*localhost* OR
  url.query:*169.254.169.254* OR
  url.query:*10.* OR
  url.query:*192.168.*
)

Exact field names vary by SIEM and proxy. Normalize URL decoding before matching because attackers may encode the protocol value or destination.

A suspicious match is an investigation lead, not proof of compromise. Correlate:

• The inbound request
• Plex process activity
• DNS lookups
• Outbound connections
• Authentication events on contacted services
• Host filesystem changes
• New accounts, scheduled tasks, or processes
• Access to cloud metadata or internal management systems

Detection is complicated by incomplete public details about Plex’s normal request patterns and the absence of a reliable universal network signature.

Remediation Steps

Upgrade every Plex Media Server instance to 1.43.3.10861 or later. The vendor identifies that version as fixed, and later versions are described as not affected by the disclosed exploit chain.

Do not stop at updating Plex clients, mobile applications, or media-library software separate from the server package.

For internet-facing deployments:

1. Upgrade Plex immediately.
2. Confirm the running server reports version 1.43.3.10861 or later.
3. Review exposure through firewalls, reverse proxies, tunnels, and remote-access services.
4. Analyze requests to /player/timeline.
5. Review outbound connections from the Plex host.
6. Investigate signs of compromise.
7. Rotate credentials that may have been exposed through the broader exploit chain.

If a vulnerable instance cannot be upgraded immediately, remove direct internet exposure, restrict access to trusted networks or a VPN, and apply egress filtering that prevents the Plex host from reaching sensitive internal services. These controls are temporary risk reduction, not a substitute for the fixed release.

Package Update Examples

The exact package command depends on the operating system and installation method. Use the supported Plex update mechanism for the host.

For a Debian or Ubuntu installation using a locally downloaded Plex package:

sudo dpkg -i plexmediaserver_<version>_amd64.deb
sudo systemctl restart plexmediaserver
sudo systemctl status plexmediaserver --no-pager

Replace <version> with the downloaded package corresponding to 1.43.3.10861 or later. Verify the package architecture and source through Plex’s official distribution channel.

For a package-managed installation:

sudo apt update
sudo apt install --only-upgrade plexmediaserver
sudo systemctl restart plexmediaserver
sudo systemctl status plexmediaserver --no-pager

Repository availability and package naming can vary. Confirm the installed version through Plex’s administrative interface or the host’s package metadata after updating. Maintain a record of the version and update time for each server.

Temporary Network Controls

If immediate upgrading is impossible, use network controls to reduce SSRF impact. Block inbound access from untrusted networks, limit Plex host egress to required destinations, and deny access to cloud metadata and internal administration ranges where feasible.

Example Linux firewall rules should be adapted to existing organizational policy:

# Example: block outbound access to IPv4 link-local metadata range
sudo iptables -A OUTPUT -d 169.254.169.254/32 -j REJECT

# Example: restrict Plex listener to a trusted network
sudo iptables -A INPUT -p tcp --dport 32400 ! -s 192.0.2.0/24 -j DROP

The example uses documentation address space and must be replaced with the organization’s real trusted network ranges. Validate firewall changes carefully to avoid disrupting legitimate media access or management.

If the product cannot be upgraded and cannot be isolated safely, discontinue exposed use in accordance with vendor and CISA guidance.

Treat vulnerable internet-facing systems as potentially compromised. Preserve relevant logs, inspect outbound connections and process activity, rotate potentially exposed credentials, and assess whether the Plex host had access to sensitive services.

CISA lists the federal remediation deadline as November 3, 2026, but organizations should not defer remediation until that date.