Plex2Shell: How to Detect & Patch Plex Media Server RCE

Executive Summary

Threat actors have initiated mass in-the-wild exploitation against internet-exposed Plex Media Server instances, leveraging an unauthenticated remote code execution (RCE) exploit chain designated as Plex2Shell. The active exploitation wave commenced within 24 hours of a public proof-of-concept (PoC) release on October 16, 2026, by independent security researcher boredhackerblog, who documented the weaponization mechanics discovered earlier by security researcher Zach Main.

The Plex2Shell exploit chain concatenates four distinct vulnerabilities—CVE-2026-96652, CVE-2026-96654, CVE-2026-96655, and CVE-2026-96656—to transition an unauthenticated external HTTP request into arbitrary native code execution on the underlying operating system. Because Plex Media Server frequently runs with elevated privileges on Linux hosts, network-attached storage (NAS) appliances, and home server environments, successful compromise grants adversaries root-level or administrative host control.

Forensic observations reveal automated payload distribution from remote infrastructure (`217.60.194.116`) executing across multiple scanning egress IPs (`91.92.40.202`, `176.65.139.228`, and `45.194.92.222`). Adversaries simultaneously deploy two persistent payloads: `myawesomeproxy`, a stealthy Linux reverse proxy linked to the AISURU proxyware botnet infrastructure (`global.relay.proxystream.st`), and `mylovelyminer`, an optimized XMRig cryptocurrency miner funneling computing resources to `ota.proxystream.st`.

Plex addressed these flaws in Plex Media Server version 1.43.3.10861 on August 3, 2026. However, hundreds of thousands of internet-accessible servers running unpatched builds remain directly exposed on default TCP port 32400.

---

Technical Vulnerability Analysis & Attack Chain

Root-Cause & Exploitation Mechanics

The Plex2Shell chain represents a textbook multi-stage architectural exploit where multiple low- and medium-severity design oversights combine to form a critical zero-click RCE vector.

[ Remote Adversary ]
       │
       │ 1. Unauthenticated HTTP POST /player/timeline (protocol injection)
       ▼
[ CVE-2026-96652: Unauthenticated SSRF ]
       │
       │ 2. Internal SSRF invokes /searchOne endpoint
       ▼
[ CVE-2026-96654: Plugin Parameter Injection ]
       │
       │ 3. Exfiltrates Server Owner Administrative Token (X-Plex-Token)
       ▼
[ CVE-2026-96655: Authenticated Transcoder SSRF ]
       │
       │ 4. Calls /video/:/transcode/universal with malicious carrier video
       ▼
[ CVE-2026-96656: Codec Directory Path Traversal ]
       │
       │ 5. Writes extracted ELF .so into Codecs/ directory
       ▼
[ Dynamic Linker Execution (dlopen) ]
       │
       │ 6. Spawns root shell, installs myawesomeproxy & mylovelyminer
       ▼
[ AISURU Proxyware Relay & Monero Mining Pool ]

Stage 1: Unauthenticated Server-Side Request Forgery (CVE-2026-96652)

The entry point resides in the /player/timeline endpoint. Plex Media Server constructs an outbound player communication URL by concatenating user-supplied input parameters without sanitization or protocol schema validation:

• The parameter protocol is embedded directly into the constructed URI string: {protocol}://{address}:{port}/....
• An unauthenticated remote attacker provides an internal URI target (e.g., protocol=http&address=127.0.0.1&port=32400), forcing the Plex daemon to issue an internal HTTP POST request on its own loopback interface.
• This SSRF completely bypasses external IP filtering and network-level access control lists (ACLs).

Stage 2: Plugin Injection & Administrative Token Theft (CVE-2026-96654)

With loopback HTTP request capabilities unlocked, the attacker targets the /searchOne internal endpoint. This endpoint suffers from an improper neutralization of URL parameters flaw:

• The parser permits the caller to inject arbitrary routing parameters and trigger internal plugin methods.
• By invoking specialized internal diagnostic and management plugin endpoints, the adversary forces the application to return internal server configuration dictionaries.
• The returned data structure contains the server owner's administrative authorization secret: the `X-Plex-Token`. Possession of this token elevates the unauthenticated external adversary to full administrative ownership of the Plex instance.

Stage 3: Authenticated Transcoder Ingestion (CVE-2026-96655)

Armed with the valid X-Plex-Token, the adversary accesses the authenticated media transcoding pipeline via /video/:/transcode/universal.

• This endpoint accepts remote media source URIs to transcode streaming media on the fly.
• The attacker directs the transcoder to download a specially crafted carrier video file hosted on remote adversary infrastructure (http://217.60.194.116/payload.mp4).
• The carrier media file contains an embedded compiled Linux ELF shared object (`.so`) structured to mimic a legitimate audio/video decoding library.

Stage 4: Codec Directory Path Traversal & Dynamic Loading (CVE-2026-96656)

When the Plex transcoder unpacks and parses codecs required to process new media formats, it handles file paths insecurely:

• An external control of file name or path vulnerability allows directory traversal sequences (../) during codec extraction.
• The embedded ELF shared object is extracted and written directly into an attacker-selected subdirectory within the Plex `Codecs` storage folder (e.g., %LOCALAPPDATA%/Plex Media Server/Codecs/ or /var/lib/plexmediaserver/Library/Application Support/Plex Media Server/Codecs/).
• When the transcoder dynamically links the newly acquired codec using standard dynamic loader calls (dlopen()), the malicious ELF library executes immediately within the context of the running Plex process.

Stage 5: In-the-Wild Post-Exploitation Deployment

Once native execution is achieved, automated shell scripts fetch and unpack two distinct binaries:

1. `myawesomeproxy`: A compiled Linux daemon that joins the compromised machine to a decentralized residential proxy network. Upon launch, the binary emits the disclaimer:

"Running this software on any of your devices makes you agree to the potential external use of your internet traffic." The proxy registers with `global.relay.proxystream.st`, a known relay domain associated with the AISURU DDoS and residential proxyware botnet.

1. `mylovelyminer`: An optimized Monero (XMR) miner built on the open-source XMRig engine. It spawns background threads tuned to consume available CPU cores while connecting to mining stratum pool `ota.proxystream.st`.

---

MITRE ATT&CK Tactics, Techniques & Procedures (TTPs)

---

Threat Actor Profile & Campaign Attribution

The rapid weaponization following the October 16 PoC release highlights opportunistic exploitation by automated botnet operators and proxyware monetizers:

Timeline of Disclosure & Exploitation:
├── July 27, 2026: Vulnerabilities disclosed to Plex by security researcher Zach Main
├── August 3, 2026: Plex ships patch in Plex Media Server v1.43.3.10861
├── October 16, 2026: Technical Plex2Shell exploit chain and PoC published by boredhackerblog
├── October 17, 2026: In-the-wild mass scanning begins from 91.92.40.202, 176.65.139.228, 45.194.92.222
└── October 18-19, 2026: Automated distribution of myawesomeproxy and mylovelyminer from 217.60.194.116

The campaign's dual payload distribution strategy demonstrates a multi-stream monetization model:

• Bandwidth Monetization: By converting victim servers into residential proxy nodes through `myawesomeproxy`, the threat actors sell victim IP reputation and bandwidth on underground commercial proxy markets to bypass anti-bot and geo-blocking restrictions.
• Infrastructure Overlap: Domain infrastructure analysis connects `global.relay.proxystream.st` to the AISURU botnet, previously documented by Bitsight in August 2026 for orchestrating high-volume distributed denial-of-service (DDoS) campaigns and proxyware infrastructure.
• Cryptojacking Monetization: Deploying `mylovelyminer` monetizes idle and active CPU cycles across media servers, many of which run 24/7 on multi-core NAS systems (Synology, QNAP, TrueNAS) and unRAID homelabs.

---

Detection & SOC Mitigation Playbook

1. Concrete Remediation & Workarounds

Defenders and home server administrators must immediately execute the following four-step containment protocol:

Step 1: Upgrade Plex Media Server

Upgrade Plex Media Server immediately to version `1.43.3.10861` or higher across all platforms:

# Debian / Ubuntu / Linux Mint
wget https://downloads.plex.tv/plex-media-server-new/1.43.3.10861/debian/plexmediaserver_1.43.3.10861_amd64.deb
sudo dpkg -i plexmediaserver_1.43.3.10861_amd64.deb
sudo systemctl restart plexmediaserver

# Docker / Container Environments
docker pull plexinc/pms-docker:latest
docker stop plex && docker rm plex
# Re-launch container with latest image

Step 2: Terminate Malicious Processes & Remove Persistence

Identify and kill rogue proxy and mining processes running under the plex user or host system:

# 1. Inspect running processes matching known malware signatures
pgrep -fl "myawesomeproxy|mylovelyminer|xmrig"

# 2. Terminate malicious processes immediately
sudo pkill -9 -f "myawesomeproxy"
sudo pkill -9 -f "mylovelyminer"

# 3. Check for suspicious cron jobs and systemd persistence
sudo crontab -u plex -l
sudo ls -la /etc/systemd/system/ | grep -iE "proxy|miner"
sudo rm -f /etc/systemd/system/myawesomeproxy.service /etc/systemd/system/mylovelyminer.service
sudo systemctl daemon-reload

Step 3: Purge Malicious Libraries from the Codecs Directory

Audit and delete unauthorized shared objects (.so) and dynamic link libraries (.dll) placed inside the Plex Codecs directory:

# Locate Plex Codecs directory (Linux standard path)
CODECS_DIR="/var/lib/plexmediaserver/Library/Application Support/Plex Media Server/Codecs"

# Check for files modified within the last 7 days
find "$CODECS_DIR" -type f -mtime -7 -ls

# Safe clean: Stop Plex, remove all cached codecs, and restart (Plex re-downloads legitimate codecs on demand)
sudo systemctl stop plexmediaserver
sudo rm -rf "$CODECS_DIR"/*
sudo systemctl start plexmediaserver

Step 4: Revoke and Regenerate Admin X-Plex-Token

Because CVE-2026-96654 exposes the server owner token, administrators must invalidate existing tokens:

1. Log in to plex.tv and navigate to Account Settings > Security.
2. Select Sign Out Everywhere to immediately invalidate all existing active session tokens.
3. Re-authenticate your server instance with fresh credentials.

---

2. Network & Perimeter Defenses

1. Disable Public Port Forwarding: Disable router NAT port forwarding for port 32400. Do not expose Plex Media Server directly to the public internet.
2. Enforce Private VPN Access: Require access to media servers through encrypted peer-to-peer tunnels such as WireGuard, Tailscale, or Pangolin.
3. Block Adversary Ingress & Egress: Configure firewall rules to drop traffic to and from known malicious infrastructure:

# UFW (Uncomplicated Firewall) Rules
sudo ufw deny from 91.92.40.202 to any
sudo ufw deny from 176.65.139.228 to any
sudo ufw deny from 45.194.92.222 to any
sudo ufw deny out to 217.60.194.116
sudo ufw deny out to any port 3333 proto tcp # Standard Stratum mining port

1. DNS Sinkholing: Implement DNS sinkholing via Pi-hole, AdGuard Home, or corporate DNS resolvers for *.proxystream.st.

---

3. Endpoint Detection & Hunting Query

Validated Sigma Rule (YAML)

The following Sigma rule detects abnormal child processes spawned by the Plex Media Server binary, signaling exploit execution:

title: Suspicious Child Process Spawned by Plex Media Server
id: 7e2d94b1-81f3-4e2a-bb56-9a24c52089e1
status: test
description: Detects unusual child processes such as shell interpreters, download utilities, or known malware payloads spawned by the Plex Media Server or Transcoder process.
references:
    - https://thehackernews.com/2026/10/hackers-exploit-plex2shell-flaws-to.html?ref=cybernewsai.com
author: CyberNewsAI Threat Research Team
date: 2026/10/19
logsource:
    category: process_creation
    product: linux
detection:
    parent_process:
        ParentImage|endswith:
            - '/Plex Media Server'
            - '/Plex Transcoder'
    target_process:
        Image|endswith:
            - '/sh'
            - '/bash'
            - '/dash'
            - '/curl'
            - '/wget'
            - '/python'
            - '/python3'
            - '/myawesomeproxy'
            - '/mylovelyminer'
            - '/xmrig'
    condition: parent_process and target_process
falsepositives:
    - Custom user notification scripts or transcoder wrapper hooks configured intentionally by server administrators.
level: critical
tags:
    - attack.execution
    - attack.t1059.004
    - attack.t1190

Microsoft Sentinel / Defender KQL Hunting Query

Hunt for anomalous child processes and suspicious outbound connections initiated by Plex binaries:

// Query 1: Detect Suspicious Process Execution Spawned by Plex Media Server
DeviceProcessEvents
| where InitiatingProcessFileName in~ ("Plex Media Server", "Plex Transcoder", "Plex Media Server.exe")
| where FileName in~ ("sh", "bash", "curl", "wget", "myawesomeproxy", "mylovelyminer", "xmrig", "cmd.exe", "powershell.exe")
| project
    TimeGenerated,
    DeviceId,
    DeviceName,
    InitiatingProcessFileName,
    InitiatingProcessCommandLine,
    FileName,
    ProcessCommandLine,
    AccountName
| order by TimeGenerated desc

// Query 2: Hunt for Network Connections to Plex2Shell Ingress & C2 Infrastructure
let c2_ips = dynamic(["217.60.194.116", "91.92.40.202", "176.65.139.228", "45.194.92.222"]);
let c2_domains = dynamic(["ota.proxystream.st", "global.relay.proxystream.st"]);
DeviceNetworkEvents
| where RemoteIP in (c2_ips) or RemoteUrl has_any (c2_domains)
| project
    TimeGenerated,
    DeviceId,
    DeviceName,
    InitiatingProcessFileName,
    RemoteIP,
    RemotePort,
    RemoteUrl
| order by TimeGenerated desc

Splunk (SPL) Hunting Query

Search for network egress to malicious mining and proxy domains across proxy and firewall logs:

index=* (dest_ip="217.60.194.116" OR dest_ip="91.92.40.202" OR dest_ip="176.65.139.228" OR dest_ip="45.194.92.222" OR query="*proxystream.st*")
| stats count earliest(_time) as first_seen latest(_time) as last_seen by src_ip, dest_ip, query, dest_port
| convert ctime(first_seen) ctime(last_seen)
| sort - count

---

(Note: Authoritative advisories identify network scanning infrastructure and payload filenames; hunt using behavioral process and network telemetry above.)