Plex2Shell Is Being Exploited: How to Check and Clean Your Plex Server

Attackers are exploiting a four-vulnerability chain in Plex Media Server to take control of internet-facing systems without a valid login, according to honeypot evidence published after working exploit code appeared online. The observed payloads include an XMRig cryptocurrency miner and software that turns the victim’s connection into a reverse proxy.

The chain, known as Plex2Shell, affects old Plex Media Server builds. The researcher’s public advisory identifies version 1.43.3.10861 as the fixed release and assigns the combined chain a critical 9.8 CVSS score. Plex separately told users in a September 1 security notice to move to Plex Media Server 1.43.3 or newer.

Anyone who exposes a Plex server to the internet should confirm the version that is actually running now. Updating closes the known path, but it does not remove malware or persistence from a server that was already compromised.

How Plex2Shell reaches code execution

Plex2Shell combines four weaknesses instead of relying on a single request. That matters because looking only for the final malware process can miss the sequence that gave an attacker control.

• CVE-2026-96652 uses the unauthenticated /player/timeline endpoint to make the server issue a request to an attacker-selected destination.
• CVE-2026-96654 turns that server-side request into a loopback pivot through the searchOne endpoint, allowing the attacker to reach internal plugin functions and obtain the server owner’s administrative token.
• CVE-2026-96655 uses the owner’s token against Plex’s transcoder path to fetch attacker-controlled media and write a file to an arbitrary location.
• CVE-2026-96656 places an unsigned shared library in Plex’s Codecs directory, where it can be loaded and executed by the server.

The result is remote code execution with the privileges of the Plex service account. That may be a dedicated, restricted account on a well-configured Linux host, but it can still expose Plex’s database, configuration, tokens, mounted media and any paths made writable to the service. A container limits some host access only when its mounts, privileges and socket access were constrained in the first place.

The vulnerabilities were reported to Plex on July 27. Technical details and proof-of-concept code became public on October 16, and in-the-wild exploitation was observed the next day. That short interval leaves little value in waiting for a NAS vendor’s package catalog or a routine container maintenance window.

Check the running Plex version, not the package label

Open Plex Web, select Settings, choose the server under the left-hand settings menu, and open General. Confirm that the displayed server version is 1.43.3.10861 or later. A package manager showing “up to date” is not enough if its catalog still serves an older build.

For Windows, macOS and conventional Linux installations, use Plex’s current package from its official download page if the built-in updater has not moved the server past the fixed version.

NAS owners should compare the version inside Plex with the version offered by the NAS app store. Plex’s notice explicitly warns that updated NAS packages may arrive late and points users to manual installation procedures for QNAP, Synology, TerraMaster, WD and other platforms.

Docker users need to pull the updated image and recreate the container. Merely restarting an existing container starts the same old image again. After recreation, return to Plex Web and verify the version reported by the running service. Also confirm that an older image tag is not pinned in Compose or another deployment file.

What to inspect for signs of compromise

The early indicators come from a limited honeypot sample, so their absence does not prove that a server is clean. Still, they give administrators a useful starting point.

• Look for processes or files named mylovelyminer and myawesomeproxy. The first observed payload was associated with XMRig; the second provided proxy functionality.
• Review outbound connections to 217.60.194[.]116 and to infrastructure under proxystream[.]st, including the mining endpoint ota.proxystream[.]st.
• Review inbound traffic from 91.92.40[.]202, 176.65.139[.]228 and 45.194.92[.]222. Treat these as investigation leads, not a complete blocklist.
• Inspect Plex’s Codecs directory for recently created or changed shared libraries that do not match the update timeline.
• Check for unexpected high CPU use, sustained outbound bandwidth, unfamiliar listening ports, new scheduled tasks or services, and connections continuing when nobody is streaming.
• Preserve Plex logs, operating-system logs, container logs and firewall or router records before deleting files or rebuilding the host.

Plex stores its main application data in different locations by platform. Its support documentation lists the defaults, including %LOCALAPPDATA%\Plex Media Server on Windows, ~/Library/Application Support/Plex Media Server on macOS and a path below /var/lib/plexmediaserver on common Linux distributions. Docker users should inspect the host directory or volume mounted as the container’s configuration path.

If the server was exposed while vulnerable

Patch immediately, then decide whether the evidence supports a full incident response. A Plex server directly reachable from the internet while running a vulnerable build should receive more scrutiny than a server limited to a trusted local network.

If suspicious files, processes or network connections appear, disconnect the system from the internet without destroying its storage. Record the running processes and connections, preserve logs, and rebuild from known-good installation media or a clean container image. Deleting the miner alone does not establish that the attacker left no additional access behind.

Rotate the Plex account password and use Plex’s option to sign out connected devices. Also replace the server claim or authentication tokens after the host is clean. Rotate any other secrets readable by the Plex service or stored on the same machine, particularly NAS administrator credentials, backup credentials, API keys and SSH keys. Review shared-library access and recent account activity for changes you did not make.

For Docker deployments, do not restore an unexamined configuration directory into the replacement container. The image may be clean while the persistent volume still contains attacker-written files. Inspect the volume, Plex plug-in locations and the Codecs directory before reuse.

Reduce exposure after the update

The patch is the immediate priority. Longer term, remove direct port forwarding when remote streaming is not required. Where remote access is necessary, restrict the service at the firewall where practical, keep Plex under a dedicated low-privilege account, and avoid broad host mounts in containers.

Do not mount the Docker socket into Plex, do not run the container as privileged, and make media libraries read-only unless Plex must modify them. Keep the configuration volume backed up separately so a clean rebuild does not depend on the potentially compromised system.

Plex2Shell is especially attractive because home media servers are often always on, reachable through residential addresses and left unattended after initial setup. The public exploit and active scanning change this from a routine update into a verify-and-investigate task: confirm the fixed build, check what the old build did before it was replaced, and rebuild when the evidence no longer supports trust.