Attackers are exploiting a chain of four Plex Media Server vulnerabilities, known as "Plex2Shell", against internet-exposed servers that have not installed the update Plex had already released by September 1. A honeypot operator first saw exploitation on the morning of October 17, one day after the researcher who found the bugs published a technical write-up and proof-of-concept code. The observed attacks dropped an XMRig-based cryptominer and a binary called "myawesomeproxy" that the honeypot operator believes is proxy software.

Plex's advisory covers Plex Media Server v1.43.2 and earlier. According to SecurityWeek, the chain lets an attacker run arbitrary code on an exposed server without valid credentials, with the same privileges as the Plex service.

Four lower-scoring bugs, one serious outcome

NVD published all four records on September 23, 2026, and each description says the flaw affects "Plex Media Server before 1.43.3.10861". The scores below are those assigned by the CVE numbering authority and shown on NVD:

  • CVE-2026-96652: server-side request forgery (SSRF) through the /player/timeline endpoint, reachable with any X-Plex-Token value. CVSS 3.1: 4.3; CVSS 4.0: 5.3.
  • CVE-2026-96654: URL values in searchOne are not correctly neutralized, allowing an attacker to call other plugins' functions with their own parameters. CVSS 3.1: 6.5; CVSS 4.0: 6.9.
  • CVE-2026-96655: authenticated SSRF through /video/:/transcode/universal. CVSS 3.1: 4.3; CVSS 4.0: 5.3.
  • CVE-2026-96656: an administrator can write arbitrary files that may be executed on load. CVSS 3.1: 7.2; CVSS 4.0: 8.6.

Three of the four score in the medium range under CVSS 3.1, and the only high-rated flaw requires administrator access on its own. The BoredHackerBlog author noted that when the CVEs appeared, none carried a CVSS score of 9 or higher. Chained together, SecurityWeek reports, they give an attacker without credentials code execution on the server.

Timeline

The sequence below comes from SecurityWeek's reporting, the Plex forum advisory, NVD, and the honeypot report:

  • July 27, 2026: The bugs are reported to Plex.
  • August 4: Plex confirms the issues and awards a bug bounty.
  • September 1: Plex posts "Important security update for Plex Media Server v1.43.2 and earlier" on its forum, saying Plex Media Server 1.43.3 and Plex Desktop 1.115.0 address several security issues and that CVEs have been requested.
  • September 23: NVD publishes the four CVE records.
  • October 16: The researcher who found the bugs publishes a write-up and proof-of-concept for the chain.
  • October 17: A honeypot run by the BoredHackerBlog author records in-the-wild exploitation that morning; myawesomeproxy appears later the same day.

The fix was available about six weeks before the details became public. How it reaches a server depends on the platform. Plex's advisory says Windows and macOS users with automatic updates enabled should confirm they are on 1.43.3 or newer. Linux users are directed to download and install the new package themselves, NAS owners are told their device's package manager may not have the update yet and to install it manually, and Docker users are pointed to the pms-docker repository instructions.

What the honeypot saw

The honeypot ran a vulnerable Plex release on the internet. Before October 17 it mostly drew reconnaissance scans and generic attack attempts, according to SecurityWeek. The BoredHackerBlog report lists 45.194.92[.]222 as the source of repeated exploitation, along with 91.92.40[.]202 and 176.65.139[.]228. Network logs showed files downloaded from 217.60.194[.]116: a Docker file and a UPX-packed binary the author identified as a cryptominer. The report also lists hashes for an xmrig binary and for myawesomeproxy. The author says the attacker may be using modified code or techniques compared with the public proof-of-concept.

The author also flags gaps in the data. The honeypot blocked outbound traffic by default, and because the exploit needs outbound connections, some payloads were not captured. Packet-capture settings had to be changed mid-collection, so coverage may be partial, and not all captures had been reviewed when the post went up. The author also cautions that the published indicators cover only what was seen on that honeypot.

The honeypot author has posted packet captures on GitHub, and the researcher who found the bugs has published detections alongside the proof-of-concept repository.

On the proxy payload, the honeypot author wrote that "Plex may be hosted on residential IP and I think threat actors would love to have residential IP proxy," raising the possibility of such access being used against corporate VPNs and email. The author presents this as speculation; it has not been confirmed.

Not on CISA's list

As of October 19, none of the four CVEs appears in CISA's Known Exploited Vulnerabilities catalog, and NVD shows no KEV date for any of them, so no federal remediation deadline has been set.

What It Means for Defenders

  • Update to Plex Media Server 1.43.3.10861 or later. On Linux, NAS appliances, and Docker, check the installed version directly instead of assuming an update ran, and rebuild Docker deployments from a current image.
  • Update Plex Desktop to 1.115.0 or later, which was part of the same security release.
  • Treat servers that were exposed and unpatched after October 16 as possibly compromised. Look for unexpected processes or containers, sustained high CPU use, and unfamiliar outbound connections. Check logs against the listed addresses and file hashes in the BoredHackerBlog report and the researcher's published detections.
  • Rebuild rather than clean in place if you find signs of compromise. Rotate credentials the Plex service account could read, including the Plex account password and tokens, and check other machines on the same network.
  • Reduce exposure. If remote access is not needed, do not expose the server directly to the internet; where it is, limit the Plex service account's file-system and network access.
  • Corporate security teams: review VPN and email sign-in logs for logins from unexpected residential IP addresses, such as an employee's home connection.

Sources