Is your Plex server being used for crypto mining via Plex2Shell exploits?

The short version

• The Plex2Shell exploit chains four vulnerabilities to achieve remote code execution without authentication.
• Wild attacks observed on 17 October 2026 deployed cryptominers and proxy tools on a test server.
• Affected systems run Plex Media Server versions prior to 1.43.3.10828, with fixes available in later builds.

The details

Researchers at Boredhackerblog recorded active exploitation of a honeypot on 17 October 2026, according to Cyber Security News. The attacks leveraged Plex2Shell, a public tool chaining four flaws to run code without logging in. Initial attempts originated from IPs including 45.194.92.222, targeting the /player/timeline/subscribe endpoint. Requests featured a Python-urllib/3.10 user agent and references to internal services and sslip.io hostnames.

The exploit chain begins with server-side request forgery, forcing the server to send attacker-chosen requests. It then accesses owner-authorized functions to write files to chosen locations. The final stage abuses unsigned codec loading to execute arbitrary code. While the exploit supports Windows and Linux, the reported wild activity targeted a Linux-based Plex deployment running in Docker. Outbound traffic restrictions initially blocked some payload collection.

The context

Plex announced security updates on 1 September 2026, urging installation of Media Server 1.43.3 and Desktop 1.115.0. The company warned NAS users might need manual updates. The vulnerabilities involved are CVE-2026-96652, CVE-2026-96654, CVE-2026-96655, and CVE-2026-96656. The Plex2Shell repository identifies versions before 1.43.3.10828 as vulnerable, listing 1.43.3.10861 as fixed.

After enabling outbound access, the researcher observed downloads from 217.60.194.116. Files named docker and x were downloaded, followed by XMRig. Subsequent updates revealed a process named myawesomeproxy and traffic to proxystream.st. The evidence shows active exploitation rather than scanning, though the number of compromised real servers remains unknown.

Next steps

• Verify your Plex Media Server version against the vulnerable list (pre-1.43.3.10828).
• Check network logs for requests to /player/timeline/subscribe with unusual user agents.
• Monitor for unexpected outbound connections to known malicious IPs or proxy domains.
• Ensure NAS users have manually applied the September 2026 security updates.

What defenders should look for

Teams usually detect this activity by monitoring for unexpected outbound connections from media servers. Check whether processes like XMRig or unknown proxies are running on systems that should only serve media. Look for web server logs showing requests to internal endpoints from external IPs with scripting user agents. Containment moves involve isolating the affected host from the network to stop data exfiltration and crypto mining. Verify that all systems are running patched software versions to prevent recurrence.

What to do and how to stay safe: Plex Media Server

• Audit all exposed Plex servers for versions prior to 1.43.3.10828 and apply updates.
• Monitor network egress for connections to known cryptomining pools or proxy services.
• Review web server access logs for requests targeting the /player/timeline/subscribe path.
• Isolate any system showing unexpected CPU usage or new processes like myawesomeproxy.

Step-by-step guide: How Virtual Patching Works: The Mechanics Behind Inline Protection

General security guidance from the Honeypot Daily newsroom. It is not confirmed advice from the organisations named in this story.

Frequently asked questions

Which CVEs are part of the Plex2Shell exploit chain?

The chain combines CVE-2026-96652, CVE-2026-96654, CVE-2026-96655, and CVE-2026-96656.

When was the wild exploitation observed?

Researchers recorded successful attacks against a honeypot on 17 October 2026.

What software was deployed by the attackers?

Attackers installed the XMRig cryptominer and a proxy tool named myawesomeproxy.