CVE-2026-96655: Plex SSRF Vulnerability
Active exploitation confirmed in CISA KEV.
Active exploitation confirmed in the wild. CISA added this to the KEV catalog on 2026-10-20. Federal agencies must patch by 2026-11-03.
TL;DR - CVE-2026-96655 is an authenticated SSRF vulnerability in Plex Media Server’s universal-transcode endpoint. - Versions before 1.43.3.10861 are affected. Upgrade to 1.43.3.10861 or later. - CISA confirms exploitation in the wild and lists the issue in its Known Exploited Vulnerabilities catalog. - A public proof of concept was released on October 16, 2026. - Investigate suspicious authentication and outbound-request activity, especially on internet-facing servers.
Summary
CVE-2026-96655 affects Plex Media Server versions before 1.43.3.10861. An authenticated user can cause the server to request arbitrary internal or external addresses through the /video/:/transcode/universal path parameter. This server-side request forgery (SSRF) issue makes the vulnerable server send network requests on an attacker’s behalf.
The numerical CVSS score is moderate, but the operational risk is higher because CISA has added the vulnerability to its Known Exploited Vulnerabilities catalog. Plex’s security announcement also states that the broader vulnerability chain was actively and widely exploited and that a public proof of concept was released on October 16, 2026.
Organizations reviewing related security controls may also benefit from this ransomware response checklist and guidance on Linux log analysis for security teams.
| Field | Details |
|---|---|
| CVE ID | CVE-2026-96655 |
| Product | Plex Media Server |
| Vulnerability | Server-side request forgery (SSRF) |
| Affected component | /video/:/transcode/universal |
| CVSS base score | 4.3 |
| CVSS vector | Not reliably available from the supplied NVD record |
| Attack vector | Network-based request to the Plex service |
| Authentication | Required |
| Privileges required | Authenticated access is required; finer-grained privilege classification is not reliably available from the supplied record |
| Affected versions | Plex Media Server before 1.43.3.10861 |
| Fixed version | 1.43.3.10861 |
| Patch available | Yes |
| CISA KEV status | Listed; added October 20, 2026 |
| CISA remediation deadline | November 3, 2026 |
| Ransomware campaign use | Unknown |
The KEV listing is the decisive prioritization signal. Do not defer remediation because the CVSS score is 4.3 or because exploitation requires authentication. Internet-facing Plex servers, installations with remote access enabled, and systems with suspicious account activity should be handled as urgent exposure and potential incident-response cases.
Analyst’s Take: Treat this as an emergency patch for any Plex server exposed to the internet, even where authentication is required. The confirmed KEV listing and public PoC outweigh the moderate CVSS score. Suspicious authentication or outbound-request activity should move the system into incident-response handling rather than routine patching.
Root Cause
The NVD description attributes the vulnerability to the universal-transcode endpoint accepting attacker-controlled path input. An authenticated attacker can manipulate the request so that Plex Media Server issues a request to an arbitrary internal or external address.
The exact implementation flaw, such as the affected validation routine or URL-parsing behavior, is not described in the supplied records and should not be inferred.
Plex becomes a network proxy from the attacker’s perspective. Depending on network placement and egress controls, the server may reach internal services, administrative interfaces, local applications, or cloud metadata endpoints that are not directly accessible to the attacker. SSRF can also provide reconnaissance and may be chained with separate weaknesses to increase impact.
The broader Plex disclosure reportedly covers multiple vulnerabilities. CISA’s associated advisory states that, in the worst case, the vulnerability set could enable credential theft, arbitrary file writing, or code execution. Those outcomes describe the broader chain and should not be treated as the standalone impact of CVE-2026-96655 without additional evidence.
For this CVE, investigate unexpected outbound requests and access to internal resources originating from Plex hosts.
Who’s Exposed
The affected product is Plex Media Server, specifically all versions before 1.43.3.10861. The CISA CSAF advisory identifies the affected version constraint as <1.43.3.10861 and identifies 1.43.3.10861 as the fixed version.
The available research does not provide a narrower affected subrange, so administrators should treat every earlier Plex Media Server release as vulnerable.
Exposure depends on deployment context as well as version. A Plex server bound only to a trusted management network may have less externally reachable attack surface than an installation published through Plex remote access, reverse proxies, port forwarding, or an internet-facing firewall rule. Authentication is still required, however, and an account compromise or unauthorized authenticated session can make an otherwise restricted instance exploitable.
Inventory teams should identify Plex installations across:
- Physical servers
- Virtual machines
- Containers
- NAS appliances
- Bundled media-server platforms
Do not assume that a vendor-managed appliance has updated itself. Verify the running Plex version directly. Also identify whether the service can make outbound connections to internal networks, cloud metadata services, directory systems, management interfaces, or other sensitive destinations.
Technical Notes
On Linux systems, administrators can inspect the running process and installed package information using commands appropriate to the installation method:
# Process command line and executable
ps -ef | grep -i '[p]lex'
# Common package-based installations
dpkg-query -W -f='${Package} ${Version}\n' 2>/dev/null | grep -i plex
rpm -qa 2>/dev/null | grep -i plex
# Container deployments
docker ps --format '{{.Names}}\t{{.Image}}' | grep -i plex
These commands are inventory aids, not proof that a system is patched. Confirm the version displayed by the Plex administration interface or the vendor’s update mechanism. Any version lower than 1.43.3.10861 should be considered exposed.
Severity Breakdown
NVD reports a CVSS base score of 4.3. The supplied research does not expose a reliable CVSS vector string, so the complete component-by-component vector must not be reconstructed or guessed.
What is established is that exploitation is network-reachable through the Plex service and requires an authenticated user. The vulnerability’s direct behavior is SSRF: the attacker induces requests from the Plex host to arbitrary internal or external addresses.
Practical impact depends heavily on:
- Network topology
- Outbound firewall policy
- Reachable services
- Credential exposure
- Cloud metadata access
- Whether other vulnerabilities can be chained
CVSS is one input to prioritization, not the final risk decision. CISA’s KEV designation confirms exploitation in the wild, while the public PoC lowers the barrier to testing and weaponization. An unpatched internet-accessible Plex server should receive emergency treatment even though the base score is moderate.
The broader disclosure’s reported possibilities, including credential theft, arbitrary file writing, and code execution, increase concern where multiple Plex issues are present. Those outcomes should trigger investigation and containment planning, but defenders should preserve the distinction between the specific SSRF entry and the broader vulnerability chain.
Exploitation Status
Exploitation in the wild is confirmed. CISA lists CVE-2026-96655 in the Known Exploited Vulnerabilities catalog, with an addition date of October 20, 2026.
The catalog’s known-ransomware-campaign field is Unknown. This means no ransomware association is established in the supplied CISA data; it does not mean exploitation is absent.
A public proof of concept exists. Plex’s official security announcement, as indexed in the supplied research, states that the vulnerabilities were actively and widely exploited and that a public proof of concept was released on October 16, 2026.
The available material does not establish that every public PoC targets this CVE in isolation rather than the broader Plex vulnerability chain. Defenders should nevertheless assume that exploitation instructions are available to attackers.
The combination of KEV status and public PoC requires rapid action. Preserve logs before patching where feasible, especially for internet-facing systems or servers with unusual authentication events. Patching removes the vulnerable code path but does not determine whether a system was previously accessed or whether internal resources were queried.
CISA’s listed remediation deadline is November 3, 2026. Organizations subject to applicable CISA directives should follow the relevant BOD 26-04 risk-based security-update guidance and CISA forensic triage requirements. Other organizations should use the deadline as a minimum benchmark rather than a reason to wait.
Sources
-
NVD, CVE-2026-96655:
https://nvd.nist.gov/vuln/detail/CVE-2026-96655 -
CVE.org record:
https://www.cve.org/CVERecord?id=CVE-2026-96655 -
CISA Known Exploited Vulnerabilities Catalog:
https://www.cisa.gov/known-exploited-vulnerabilities-catalog?field_cve=CVE-2026-96655 -
CISA CSAF advisory:
https://raw.githubusercontent.com/cisagov/CSAF/develop/csaf_files/IT/white/2026/va-26-266-01.json -
Plex security announcement:
https://forums.plex.tv/t/important-security-update-for-plex-media-server-v1-43-2-and-earlier/942319
The cited records establish the affected range, fixed version, SSRF behavior, KEV status, and exploitation context. The supplied research does not provide a reliable CVSS vector string, a validated exploit signature, or a specific vendor-supported temporary configuration workaround. Treat those fields as unknown rather than infer them, while proceeding with the confirmed upgrade and exposure-reduction measures above.
This article may contain affiliate links. We earn a commission on qualifying purchases at no extra cost to you.
Detection Guidance
Detection should combine version inventory, web or application logs, authentication telemetry, and outbound network monitoring. A vulnerable Plex server may not show a distinctive exploit string in every log format, and the supplied research does not provide a validated network signature. Avoid relying on a single indicator.
Prioritize requests to /video/:/transcode/universal containing:
- Unusual path parameters
- Absolute URLs
- Encoded URL delimiters
- Private-address destinations
- Loopback addresses
- Link-local addresses
- Cloud metadata targets
Correlate those requests with the authenticated account, source address, user-agent, response code, and outbound connections from the Plex host. Unexpected access to internal HTTP services shortly after a Plex request is particularly important.
Technical Notes
A generic web-server query can identify suspicious universal-transcode requests. Field names vary by platform, so adapt the query to the local schema:
index=web OR index=plex
uri_path="/video/:/transcode/universal"
(uri_query="*http://*" OR uri_query="*https://*" OR
uri_query="*169.254.169.254*" OR uri_query="*127.0.0.1*" OR
uri_query="*localhost*" OR uri_query="*10.*" OR
uri_query="*172.16.*" OR uri_query="*192.168.*")
| stats count min(_time) as first_seen max(_time) as last_seen
values(src_ip) as source_ips values(user) as users
values(status) as status by host, uri_path
For environments using Microsoft Sentinel or another KQL-compatible platform, a normalized request table could be queried as follows:
CommonSecurityLog
| where RequestURL has "/video/:/transcode/universal"
| where RequestURL matches regex
@"(?i)(https?://|169\.254\.169\.254|127\.0\.0\.1|localhost|10\.\d+\.\d+\.\d+|192\.168\.\d+\.\d+)"
| summarize Count=count(), FirstSeen=min(TimeGenerated), LastSeen=max(TimeGenerated),
Sources=make_set(SourceIP), Users=make_set(DeviceCustomString1)
by DeviceHostName, RequestURL
Network teams should monitor egress from Plex hosts to destinations that are not part of normal media-server operations. Useful signals include connections to:
- RFC 1918 ranges
- Loopback or link-local destinations
- Cloud metadata addresses
- Administrative ports
- Internal web services
These are detection leads rather than proof of exploitation. Validate them against known Plex integrations and administrator activity.
After identifying a suspicious request, review authentication logs around the same timestamp. Look for:
- Newly created accounts
- Password changes
- Logins from unusual geographies or networks
- Repeated failures followed by success
- Access tokens or sessions not associated with expected users
Preserve relevant logs, reverse-proxy records, firewall flow data, and host telemetry before rotating or deleting evidence.
Remediation Steps
Upgrade every affected installation to Plex Media Server 1.43.3.10861 or later. The fixed version is explicitly identified by the CISA CSAF advisory and Plex’s security update.
Prioritize:
- Internet-facing systems
- Systems with remote access enabled
- Hosts with suspicious authentication activity
- Hosts with suspicious outbound requests
- Systems that can reach sensitive internal services
The upgrade alone is not sufficient for systems that may already have been targeted. Before or during remediation, capture relevant logs and configuration, identify active sessions, review administrator accounts, and assess whether credentials or tokens associated with Plex users may have been exposed.
If compromise indicators exist:
- Isolate the server
- Preserve forensic evidence
- Rotate affected credentials from a trusted system
- Revoke suspicious sessions and tokens
- Follow the organization’s incident-response process
Technical Notes
The exact upgrade command depends on the operating system, package source, container image, or NAS platform. Do not substitute an unverified package name or repository. Use the Plex-supported update mechanism and confirm that it installs 1.43.3.10861 or a later release.
For a container deployment, pin the image to a vendor-provided release that contains the fixed Plex version, then recreate the container according to the organization’s change process. A verification pattern is:
docker inspect plex \
--format '{{.Config.Image}} {{.Image}}'
docker exec plex sh -c 'ps -ef | grep -i "[p]lex"'
For package-managed Linux systems, update the configured Plex repository metadata and upgrade the installed package using the platform’s normal package manager. Verify the resulting version after the service restarts:
# Debian/Ubuntu-style systems
sudo apt update
sudo apt install --only-upgrade plexmediaserver
sudo systemctl restart plexmediaserver
# RPM-based systems
sudo dnf upgrade plexmediaserver
sudo systemctl restart plexmediaserver
These commands assume the official Plex package is already configured and that the package is available through that repository. Confirm the installed version in the Plex administration interface. Do not consider the system remediated until it reports 1.43.3.10861 or later.
If immediate patching is impossible, reduce exposure rather than treating a workaround as a fix:
- Disable internet publication and remote access.
- Restrict inbound access with firewall or reverse-proxy allowlists.
- Require access through a trusted VPN.
- Limit outbound traffic from the Plex host to destinations required for normal operation.
- Temporarily shut down an exposed vulnerable instance if effective mitigation is unavailable.
Because CISA directs organizations to apply vendor mitigations and discontinue use where mitigations are unavailable, temporarily shutting down an exposed vulnerable instance may be the safest option.
After upgrading, review the server for evidence of prior exploitation. Search historical access logs for the universal-transcode path and suspicious destination values, correlate them with outbound network telemetry, and investigate anomalous authentication. If evidence cannot be ruled out, treat the host as potentially compromised and conduct a structured forensic review.