Pulp-style illustration of a robot hand sliding a red cartridge into a brass projector

Plex2Shell is being exploited: patch Plex, then assume compromise

ALERT · Actively exploited. Last updated 23 October 2026. See the Alert Tracker

A four-bug chain in Plex Media Server, dubbed Plex2Shell, is being used to plant cryptominers and proxy software. The fix has been out since 4 August. If your server missed it and faces the internet, Plex’s own advice is to assume it has been compromised.

What happened

On 16 October 2026 the researcher behind zmain.info published a write-up and proof of concept for four vulnerabilities in Plex Media Server. Chained together, they take an unauthenticated attacker from a network request to code execution on the host. The researcher scores the chain at 9.8.

None of this was a zero-day. According to the write-up, the bugs were reported to Plex on 27 July, Plex acknowledged them and paid a bounty on 4 August, and CVE numbers followed on 23 September. The fixed release, 1.43.3.10861, shipped on 4 August. The problem is the long tail of servers that never took it.

Within a day of the proof of concept, attacks began. BleepingComputer, citing a honeypot researcher, dates the first reports of exploitation to 17 October; Ars Technica reports scanning and infections within a day of the proof of concept. CISA has added the chain to its Known Exploited Vulnerabilities catalogue, added on 20 October; US federal agencies have until 23 October for CVE-2026-96654 and -96656, and until 3 November for -96652 and -96655.

Plex has updated its security notice, first posted on 1 September, in unusually plain language: “These vulnerabilities are being actively and widely exploited. A public proof of concept was released on October 16.”

How the chain works

CVEWhat it does
CVE-2026-96652Unauthenticated SSRF via /player/timeline
CVE-2026-96654URL injection in searchOne
CVE-2026-96655Authenticated SSRF in the transcoder
CVE-2026-96656Arbitrary file write through transcoder settings
Source: CISA KEV and BleepingComputer; Plex’s own CVE summaries differ for 96654 and 96655.

The design flaw at the centre is trust in loopback. Requests from 127.0.0.1 skip authentication, and the server helpfully attaches the owner’s token to its own outbound requests to http://127.0.0.1. The first two bugs let an outsider steer the server into making such requests on their behalf, which gets them the authenticated transcoder bugs for free.

The last step is a file write. A crafted TranscoderH264Options value with dump-yuv= drops a shared object into Codecs/<setid>-linux-x86_64/. Plex’s bundled libavutil.so.58 then loads every .so it finds in that directory through avpriv_load_new_libs. The attacker’s constructor runs as the plex user. A codec folder that executes anything left in it was always going to end badly.

Who is affected

Any Plex Media Server older than 1.43.3.10861. The serious exposure is servers reachable from the internet, typically through remote access or a forwarded port 32400. Plex’s notice says: “If your server is older than 1.43.3.10861 and reachable from the internet, assume it may be compromised.”

The Linux path is the one documented in the write-up, but Plex’s list of indicators includes unfamiliar .dll files as well as .so files, so don’t assume Windows installs are off the hook.

What to look for

Plex lists these signs:

  • Processes named myawesomeproxy, mylovelyminer or x12345.
  • Unfamiliar .so or .dll files in the Plex Codecs directory.
  • Outbound connections to proxystream.st.
  • High CPU while the server is supposedly idle. Your electricity bill may spot this before you do.

Our Hunt Lab piece has untested draft Sigma rules for the codec drop and for odd child processes of Plex on Linux.

What to do

  1. Update to 1.43.3.10861 or later, and check the version the server reports rather than the one you think you installed.
  2. If the server was exposed and out of date, treat it as compromised. Plex recommends rebuilding from a clean install. At the very least, delete the contents of the Codecs directory and check Preferences.xml for settings you didn’t make.
  3. Rotate access. Sign out all devices and change the Plex account password.
  4. Think about blast radius. Anything the Plex service account could read or reach should be considered exposed. On a home lab that is often the whole NAS.
  5. Stop publishing the server directly. Disable remote access if you don’t need it, and don’t forward port 32400 to the internet.

Also in the KEV batch

The same round of KEV additions included Siemens Software Center CVE-2026-110936, linked to the Romulus ClickFix campaign and fixed in 4.0.9.8, and EG Secure Solutions SiteGuard Server Edition CVE-2026-106931. See CISA’s KEV catalogue and Siemens advisory SSA-580366; the Romulus link is from BleepingComputer’s report.

What to tell the board

A media server is rarely on anyone’s asset register, yet this one runs with access to large file shares and often sits on a forwarded port. The patch was available for ten weeks before the proof of concept. That gap is the finding: consumer-grade software inside the estate, outside the patching process. Like PHP2Shell this month, it is also a reminder that exploitation now follows publication within a day.

For more on what is being exploited now, and what to patch first, see Threats & Vulnerabilities.

Sources