Plex2Shell CVE-2026-96652: Detection, Hunting and Patching

Plex2Shell is the name for a chain of Plex Media Server vulnerabilities, CVE-2026-96652, CVE-2026-96654, CVE-2026-96655 and CVE-2026-96656. Chained together, they let an unauthenticated attacker who can reach the Plex port, TCP 32400 by default, run code as the Plex Media Server service account. Each CVE alone is rated medium or high, but the researcher who found them rates the chain 9.8.

Plex fixed the chain in 1.43.3.10861 on August 4, 2026, and posted a security notice urging owners to update on September 1, before any CVE details were public. The details and a working proof of concept went public on October 16, and a honeypot was exploited the next morning. Plex says the flaws are now “being actively and widely exploited”, and CISA added all four CVEs to its Known Exploited Vulnerabilities catalog on October 20.

QNAP reports compromised NAS devices

On November 6, 2026, QNAP published a security notice saying it “has received reports from some users that Plex Media Server on their NAS appears to have been compromised”. QTS and QuTS hero are not themselves vulnerable. The exposure is the Plex app many owners install from App Center and open to the internet for remote streaming.

QNAP’s advice goes further than an update. If Plex 1.43.2 or earlier was reachable from the internet, through Plex Remote Access, a forwarded port 32400, UPnP or myQNAPcloud auto router configuration, QNAP says to treat the NAS and its data as compromised, reinstall Plex cleanly, reset Plex and NAS credentials, and rotate keys for services such as backup jobs and cloud connections. Updating does not remove anything an attacker already installed.

A Plex server rarely sits alone. It usually runs on a NAS, a home lab host or a small office server with read access to shared folders, and sometimes with credentials for backups and cloud storage. Payloads seen so far are cryptocurrency miners and residential proxy software, but the attacker has a shell, and whatever the Plex account can reach is exposed.

How the attack works

1. SSRF without a login (CVE-2026-96652). The /player/timeline endpoint accepts any value in the X-Plex-Token header and takes a full URL in its protocol parameter, so the server makes a POST request to an address the attacker chooses.
2. Calling internal plugin functions (CVE-2026-96654). URL values passed to the searchOne function are not neutralized, so a request the server makes to itself over the loopback interface can call other plugins’ functions with the attacker’s parameters. The public chain uses this to obtain the server owner’s admin token.
3. SSRF as an authenticated user (CVE-2026-96655). With a token, the path parameter of /video/:/transcode/universal makes the server fetch arbitrary internal or external addresses.
4. File write and code execution (CVE-2026-96656). The TranscoderH264Options preference is appended verbatim to the x264 encoder’s options on every transcode, which lets an admin write a file into the server’s Codecs folder. Plex loads every library in that folder without checking its name, signature or execute bit, so the planted .so or .dll runs when the transcoder starts.

The public chain uses DNS names such as 127.0.0.1.<attacker-ip>.sslip.io, which look like loopback but resolve to the attacker, to bounce requests between the server and the attacker. Plex’s own table describes CVE-2026-96654 and CVE-2026-96655 slightly differently; the descriptions here follow the CVE records published by CISA.

Vulnerability details

CVSS and EPSS from NVD and FIRST, exploitation status from the CISA Known Exploited Vulnerabilities catalog, checked November 8, 2026.

CISA’s advisory for the same release, VA-26-266-01, also lists CVE-2026-96651, a path traversal through /system/agents/media/get that lets an attacker with a valid session token read any file the Plex user can read, including the PlexOnlineToken that controls the Plex account. It is not part of the exploited chain or the KEV listing, and 1.43.3.10861 fixes it too.

Affected and fixed versions

Every Plex Media Server build before 1.43.3.10861 is affected, on every platform. Plex’s advisory title says “v1.43.2 and earlier”; early 1.43.3 builds such as 1.43.3.10828 (July 14) are also below the fixed build.

Plex Desktop 1.115.0 was released at the same time to fix separate client issues.

Who is exposed, in priority order

1. Plex servers reachable from the internet that ran a build before 1.43.3.10861 at any time after October 16. Plex says to assume they may be compromised.
2. QNAP and other NAS devices running the Plex app with Remote Access on, port 32400 forwarded, or UPnP enabled. NAS app stores often lag behind Plex’s own releases.
3. Servers that share a host with something valuable: a NAS that also holds backups or business files, a home lab that reaches a corporate VPN, or a staff member’s home server used for remote work.
4. Servers reachable only on a LAN. The chain needs network access to port 32400, so an attacker already inside the network can still use it.

How to check a server

Version. In Plex Web, open Settings, General. From the server itself:

# Version from the local identity endpoint (any platform)
curl -s http://127.0.0.1:32400/identity | grep -o 'version="[^"]*"'

# Debian and Ubuntu packages
dpkg-query -W plexmediaserver

# RHEL, Fedora and CentOS packages
rpm -q plexmediaserver

Data folder. Most checks happen in the Plex data folder:

Preferences. A TranscoderH264Options value you did not set is a strong sign of the file write. Values containing dump-yuv or stats= are the exploit’s signature. The public proof of concept clears the value afterward, so an empty TranscoderH264Options attribute also deserves a look.

cd "/var/lib/plexmediaserver/Library/Application Support/Plex Media Server"
grep -o 'TranscoderH264Options="[^"]*"' Preferences.xml

Codecs folder. List every .so and .dll under Codecs with its modification time, and compare against when the server was last updated. Libraries with odd names, such as zz followed by digits in the public proof of concept, or ones written after October 16 outside an update, are suspicious.

find Codecs -type f \( -name '*.so' -o -name '*.dll' \) -printf '%TY-%Tm-%Td %TH:%TM  %s  %p\n' | sort

Plex logs. Plex keeps only a few rotated logs in Logs/, so copy the folder before changing anything. Then search for the request patterns the chain leaves:

cd Logs
# Timeline requests that carry a URL scheme in the protocol parameter (CVE-2026-96652)
grep -aiE '/player/timeline/subscribe\?([^ ]*&)?protocol=[a-z0-9+.-]{1,16}(%3a|%253a|:)' Plex\ Media\ Server*.log
# searchOne calls that reach another plugin's function (CVE-2026-96654)
grep -aiE 'searchOne\?[^ ]*identifier=[^& ]*(%2f|%252f|/)function(%2f|%252f|/)' Plex\ Media\ Server*.log
# Loopback-looking callback names and the x264 file-write options
grep -aiE '(sslip|nip)\.io|TranscoderH264Options(=|%3d)[^& ]*(dump(-|%2d)yuv|stats(=|%3d))' Plex\ Media\ Server*.log

Processes and network. Look for processes started by Plex that you do not recognize, especially myawesomeproxy, mylovelyminer, x12345 or xmrig, outbound connections to proxystream.st, and sustained high CPU while nothing is playing. On QNAP, run Malware Remover; QNAP lists detection MR2104 for this activity.

Mitigation and remediation

1. Update to Plex Media Server 1.43.3.10861 or later. Take the current release, 1.43.5.11079.
2. Close the exposure if you do not need remote streaming: turn off Settings, Remote Access, remove the port 32400 forward, disable UPnP on the router, and remove any myQNAPcloud auto router configuration for Plex. Use a VPN for remote access instead.
3. If remote access must stay, put Plex behind a reverse proxy with access control, and block requests to /player/timeline that carry a URL in the protocol parameter until the server is updated.
4. Check for compromise with the steps above before deciding the update was enough.
5. Deploy detections at the perimeter if you have them: SonicWall IPS signatures 22567, 22568 and 22569 cover the chain’s requests.

Threat hunting

Plex logs rarely reach a SIEM, so the hunts below lean on endpoint, DNS and firewall telemetry that often does. The KQL is example code for Microsoft Defender for Endpoint and Microsoft Sentinel. Adapt table and field names to your environment and test each query before relying on it.

Hunt 1: Plex reachable from the internet

// Example: Sentinel CommonSecurityLog, inbound connections to Plex from public addresses
CommonSecurityLog
| where TimeGenerated > ago(30d)
| where DestinationPort == 32400
| where not(ipv4_is_private(SourceIP))
| where DeviceAction !in~ ("deny", "drop", "block", "reset")
| summarize Connections = count(), Sources = dcount(SourceIP), FirstSeen = min(TimeGenerated), LastSeen = max(TimeGenerated)
    by DestinationIP, DeviceVendor, DeviceProduct
| order by Sources desc

// Example: Defender for Endpoint, hosts accepting Plex connections from the internet
DeviceNetworkEvents
| where Timestamp > ago(30d)
| where ActionType == "InboundConnectionAccepted" and LocalPort == 32400
| where RemoteIPType == "Public"
| summarize Sources = dcount(RemoteIP), FirstSeen = min(Timestamp), LastSeen = max(Timestamp) by DeviceName

Every device on these lists needs the version check, and the compromise checks if it ran an affected build after October 16.

Hunt 2: loopback-looking callback names

The chain makes the Plex server look up names such as 127.0.0.1.<attacker-ip>.sslip.io. Legitimate use of these wildcard DNS services exists in development, but a lookup from a Plex host is a strong lead.

// Example: Defender for Endpoint, connections and DNS lookups to wildcard loopback names
DeviceNetworkEvents
| where Timestamp > ago(30d)
| where RemoteUrl has_any ("sslip.io", "nip.io")
| project Timestamp, DeviceName, InitiatingProcessFileName, RemoteUrl, RemoteIP, RemotePort
| order by Timestamp desc

// Example: Sentinel DnsEvents (Windows DNS server logs)
DnsEvents
| where TimeGenerated > ago(30d)
| where Name has_any ("sslip.io", "nip.io")
| where Name startswith "127.0.0.1." or Name startswith "127-0-0-1"
| project TimeGenerated, ClientIP, Name, IPAddresses

Hunt 3: processes started by Plex

Legitimate Plex helper processes all start with “Plex”, such as Plex Transcoder, Plex Media Scanner and Plex Tuner Service. A shell, downloader or unknown binary under Plex is the payload.

// Example: Defender for Endpoint, unexpected children of Plex processes
DeviceProcessEvents
| where Timestamp > ago(30d)
| where InitiatingProcessFileName startswith "Plex"
| where not(FileName startswith "Plex")
    or FileName in~ ("sh", "bash", "dash", "busybox", "curl", "wget", "python3", "perl", "nc", "cmd.exe", "powershell.exe", "rundll32.exe")
    or FileName in~ ("myawesomeproxy", "mylovelyminer", "x12345", "xmrig", "x", "docker")
| project Timestamp, DeviceName, InitiatingProcessFileName, FileName, ProcessCommandLine, AccountName, SHA256
| order by Timestamp desc

Expect a little noise from Plex’s own updater and scripts. Review each result, and treat /dev/tcp/ in a command line, or script -qc /bin/bash /dev/null, as an interactive reverse shell.

Hunt 4: libraries written into the Codecs folder

// Example: Defender for Endpoint, new libraries in Plex's Codecs folder
DeviceFileEvents
| where Timestamp > ago(30d)
| where FolderPath has "Plex Media Server" and FolderPath has "Codecs"
| where FileName endswith ".so" or FileName endswith ".dll"
| where ActionType in ("FileCreated", "FileModified", "FileRenamed")
| project Timestamp, DeviceName, FolderPath, FileName, InitiatingProcessFileName, InitiatingProcessCommandLine, SHA256
| order by Timestamp desc

Plex downloads codecs itself after updates. A library written by Plex Transcoder, or one written outside an update window, is the exploit’s file write.

Hunt 5: transcoder preference changes on Windows

// Example: Defender for Endpoint, TranscoderH264Options set in the Plex registry key
DeviceRegistryEvents
| where Timestamp > ago(30d)
| where RegistryKey has @"Plex, Inc.\Plex Media Server"
| where RegistryValueName == "TranscoderH264Options"
| project Timestamp, DeviceName, ActionType, RegistryValueData, InitiatingProcessFileName

Hunt 6: known infrastructure and files

// Example: Defender for Endpoint, published Plex2Shell indicators
let BadIPs = dynamic(["45.194.92.222", "91.92.40.202", "176.65.139.228", "217.60.194.116"]);
let BadDomains = dynamic(["proxystream.st"]);
let BadHashes = dynamic([
  "5712ef510481f15fe8b18fdd10b73026d57cb3d9d151878a692358b99a464441",
  "68938fb428f2bcfef4ede62f7b29cd0f15f37ed59e94462c099f2ca64e36baa7",
  "b20f39fc00d242e706b6c30367ad811c676e0575050a4ec2f30104b696944b49",
  "e546b10aee5edc754da4f9b0baace00392257121911f630145078eafad1e6bd9",
  "2d3c618b21a7e2f8bcd735da188e44a7609ff3f204832dd0781cd09e4388c9db"]);
union
  (DeviceNetworkEvents
   | where Timestamp > ago(30d)
   | where RemoteIP in (BadIPs) or RemoteUrl has_any (BadDomains)
   | project Timestamp, DeviceName, Indicator = coalesce(RemoteUrl, RemoteIP), InitiatingProcessFileName),
  (DeviceFileEvents
   | where Timestamp > ago(30d)
   | where SHA256 in (BadHashes)
   | project Timestamp, DeviceName, Indicator = SHA256, InitiatingProcessFileName = FileName)
| order by Timestamp desc

// Example: Sentinel CommonSecurityLog, firewall traffic to or from the same addresses
let BadIPs = dynamic(["45.194.92.222", "91.92.40.202", "176.65.139.228", "217.60.194.116"]);
CommonSecurityLog
| where TimeGenerated > ago(30d)
| where SourceIP in (BadIPs) or DestinationIP in (BadIPs) or RequestURL has "proxystream.st"
| project TimeGenerated, SourceIP, DestinationIP, DestinationPort, DeviceAction, RequestURL

The published addresses come from a single honeypot over a few days, and the public exploit’s ports and file names are easy to change. A miss on Hunt 6 does not clear a server; Hunts 2 to 5 matter more.

Responding to a compromise

1. Preserve evidence first: copy the Plex Logs folder, Preferences.xml (or the Windows registry key), and the Codecs folder before removing anything. QNAP asks for the Logs folder if you want its support team to confirm a compromise.
2. Isolate the host from the internet and from file shares while you work.
3. Rebuild, do not clean. Plex and QNAP both say to reinstall from a clean installation rather than reuse the old Plex data folder. At minimum, delete everything in Codecs, remove TranscoderH264Options values you did not set, and let Plex download codecs again. On a NAS, QNAP recommends a clean reinstall of the Plex app and treating the whole device as exposed.
4. Reset credentials in the right order: sign out of all devices in the Plex account settings first, because the admin token may have been stolen, then change the Plex password. Change NAS administrator and user passwords, turn on two-step verification, and rotate passwords and keys for backup jobs, cloud connections and anything else stored on the host.
5. Treat reachable data as exposed: mounted shares, media folders, backups and any credentials the Plex service account could read.
6. Check the rest of the network for connections from the Plex host to internal systems after the first exploit date.

Indicators of compromise

Addresses and domains are defanged. Network indicators come from one honeypot over a few days, so use them for retro hunting rather than as proof of safety.

Network

Files (SHA-256)

Host

• Processes started by Plex named myawesomeproxy, mylovelyminer, x12345 or xmrig
• Unfamiliar .so or .dll files in the Plex Codecs folder
• TranscoderH264Options containing dump-yuv or stats=
• QNAP Malware Remover detection MR2104

Detection rules

Timeline

• July 27, 2026: Researcher Zach Main reports the vulnerabilities to Plex.
• August 3 and 4, 2026: Plex releases 1.43.3.10861 to Beta, then to everyone. Plex acknowledges the report on August 4.
• September 1, 2026: Plex posts a security notice urging all owners to update, with CVE details to follow.
• September 23, 2026: CISA publishes the CVEs and advisory VA-26-266-01.
• October 16, 2026: The researcher publishes the technical write-up and proof of concept.
• October 17, 2026: A Plex honeypot is exploited, and attackers install an XMRig miner and myawesomeproxy.
• October 19, 2026: Plex publishes the CVE details and says the flaws are being actively and widely exploited.
• October 20, 2026: CISA adds all four CVEs to KEV. Federal deadlines are October 23 for CVE-2026-96654 and CVE-2026-96656, and November 3 for CVE-2026-96652 and CVE-2026-96655.
• October 29, 2026: SonicWall publishes IPS signatures for the chain.
• November 6, 2026: QNAP reports compromised Plex servers on customer NAS devices and publishes a check and remediation guide.

Frequently Asked Questions

Is this the same as PHP2Shell? No. PHP2Shell (CVE-2026-109618 and CVE-2026-109619) is a flaw in the PHP runtime. Plex2Shell is a separate chain in Plex Media Server. Both are being exploited, and both have reached NAS devices, which is why the names get mixed up. See our PHP2Shell advisory.

Is QNAP’s operating system vulnerable? No. QNAP says the vulnerabilities exist only in Plex Media Server, not in QTS, QuTS hero or other QNAP software. A QNAP NAS is at risk only if it runs an affected Plex app that attackers can reach.

We updated Plex. Are we done? Only if the server was never reachable from the internet on an affected build after October 16. Otherwise, check for compromise. The update closes the entry point but does not remove a miner, proxy or planted codec already on the system.

The chain includes an admin-only bug. Why is it unauthenticated? The first steps steal the server owner’s admin token through request forgery, so the attacker never needs a password. That is also why Plex says to sign out of all devices before changing the Plex password.

We only use Plex inside the office network. Are we exposed? Less, but not safe. Anyone who can reach port 32400 can run the chain, including an attacker who already has a foothold on the network. Update it anyway.

Why are the CVSS scores so different? Each CVE is scored on its own, from 5.3 to 8.6 under CVSS 4.0. The researcher scores the full chain 9.8, because together they give unauthenticated code execution.

What do attackers do with a compromised server? So far, run cryptocurrency miners and residential proxy software that routes other people’s traffic through the victim’s connection. The attacker has a shell, though, so data on the host and on mounted shares should be treated as exposed.

How ThreatDefence is responding

ThreatDefence has added the Plex2Shell CVEs and indicators to our threat intelligence. Where we hold endpoint, DNS and firewall telemetry, our SOC is:

• finding Plex servers and NAS devices reachable on port 32400 from the internet
• alerting on lookups of loopback-looking wildcard DNS names, unexpected processes started by Plex, and new libraries in the Plex Codecs folder
• matching published addresses and file hashes against retained logs back to October 16

If Plex runs anywhere in your environment, including on a NAS or a staff home server used for remote work, and you want help checking it or investigating a suspected compromise, contact us. Read more about our managed detection and response.

Sources

• Plex, Important Security Update for Plex Media Server v1.43.2 and earlier (September 1, 2026, updated October 19, 2026)
• Plex, Plex Media Server 1.43.3.10861 release (August 4, 2026)
• QNAP, Security notice: Plex Media Server vulnerabilities (Plex2Shell) (November 6, 2026)
• QNAP, Plex2Shell check and remediation FAQ for QNAP NAS users (November 6, 2026)
• CISA, Known Exploited Vulnerabilities Catalog (October 20, 2026)
• CISA, CSAF advisory VA-26-266-01, Plex Media Server (September 23, 2026)
• CVE Program, CVE-2026-96652
• CVE Program, CVE-2026-96654
• CVE Program, CVE-2026-96655
• CVE Program, CVE-2026-96656
• Zach Main, Plex2Shell write-up (October 16, 2026)
• BoredHackerBlog, Plex vulnerabilities being exploited in the wild (October 17, 2026)
• SonicWall Capture Labs, Plex2Shell: Plex Media Server exploit chain (October 29, 2026)
• VirusTotal, myawesomeproxy sample
• VirusTotal, x payload sample