How to Check a Plex Server for Compromise

To check a Plex server for compromise after the Plex2Shell attacks, confirm the build is 1.43.3.10861 or newer, then look for four things: unknown processes started by Plex, unfamiliar library files in the Codecs folder, transcoder options in Preferences.xml that you did not set, and outbound traffic to proxy domains. Updating alone does not remove a planted file. The background is in our report on Plex2Shell exploitation and the CISA KEV listing.

Do you need to check a Plex server for compromise?

Yes, if the server ran a build older than 1.43.3.10861 and was reachable from the internet at any point since October 16, 2026. Plex's own guidance is to assume such a server may be compromised until you have checked it.

If the server was only ever reachable on the local network, the risk is lower but not zero. Any compromised device on the same network could have reached it.

Step 1: Confirm the version

Open Plex Web, go to Settings, then General, and read the version string. You want 1.43.3.10861 or later. Compare the full build number, because an earlier 1.43.3 build (10828) was also released.

If you are below that build, update before going further. On a NAS, the vendor app store may lag behind, so download the package from the Plex downloads page and install it manually. Docker users should follow Plex's pms-docker repository instructions to pull the current image.

Updating first stops reinfection while you investigate. It does not remove anything already planted.

Step 2: Look for processes Plex should not be running

Plex Media Server normally runs a handful of its own helper processes, such as the transcoder and the plugin framework. Use your platform's process viewer (Task Manager on Windows, Activity Monitor on macOS, the process list on Linux or in the NAS admin panel) and look at what runs under the Plex service account.

The names reported in the October 2026 attacks were myawesomeproxy, mylovelyminer (an XMRig miner) and x12345. Attackers rename binaries, so treat any process under the Plex account that you cannot explain as suspicious, not just these three.

High, sustained CPU use while nothing is streaming or transcoding is the other strong signal. That points to a miner.

Step 3: Inspect the Codecs folder

How does the Plex2Shell implant survive a restart? It sits as a library in the Plex Codecs folder, which the transcoder loads on every start without checking signatures.

The Codecs folder lives under the Plex data directory, in set directories named by a hash and platform. Plex downloads its own codec libraries there. Look for files with a different timestamp from their neighbors, names that do not match the rest of the set, or anything added after October 16. On Linux the planted files are .so libraries; on Windows they would be .dll.

If you find anything you cannot account for, stop and go to step 6. Do not just delete the file and carry on.

Step 4: Review Preferences.xml

The attack chain changes a transcoder preference to write its file, and the researcher's proof of concept clears it afterward. A careless operator may leave it set. Open Preferences.xml in the Plex data directory and look for transcoder option attributes you never configured. Most servers never touch the H.264 encoder options, so any value there deserves a second look.

A clean Preferences.xml does not prove the server is clean. A modified one is strong evidence that it was compromised.

Step 5: Check outbound connections

From the host or your firewall logs, look for connections to proxystream.st and its subdomains, and to the addresses reported in the campaign (217.60.194[.]116 for payload hosting). A media server should mostly receive connections. Steady outbound sessions to relay hosts mean proxyware, which our explainer on what proxyware is and why attackers install it covers in more detail.

Also check DNS logs, since they keep a record of lookups even after the process has been killed.

Step 6: What do you do if you find something?

Rebuild the server from a clean installation and do not reuse the old Plex data directory. Then sign out of all devices from your Plex account, change the Plex password and treat everything the Plex account could reach as exposed.

That last part matters most on business networks. List what the Plex service account could read: mounted media shares, other folders on the same NAS, credentials saved on the same machine or VM. Rotate those credentials after the rebuild, not before. Our guide on why to rebuild before you rotate credentials explains why the order matters.

Step 7: Reduce the exposure

If no one streams from outside the house or office, turn off Remote Access in Plex settings and remove any router rule forwarding port 32400. If remote streaming is needed, put the server behind a VPN instead of exposing it directly.

The four Plex2Shell bugs each looked moderate on paper. Our piece on why vulnerability chaining beats CVSS scores in triage explains why a server with "medium" findings still needed an urgent patch.