Plex2Shell Explained: Exploited Plex Media Server Flaws and Fixes

Plex2Shell is a chain of four Plex Media Server flaws that, per the researcher and Plex, lets an unauthenticated remote attacker run code as the server process. Every build before 1.43.3.10861 is affected. Attacks started a day after the public proof of concept, and CISA added all four CVEs to its exploited list. Update now, then check for miners.

What happened

Plex Media Server is the software people run at home, in small offices and on NAS boxes to stream their own media. It listens on TCP port 32400, and its Remote Access feature makes it reachable from outside the home network.

Researcher Zach Main reported the flaws privately in July. Plex shipped a fix in early August, warned users on 1 September, and the CVE records went public on 23 September. The write-up and exploit code followed on 16 October; the first honeypot attack came the next morning.

Timeline

Two dates in that table rest on a single outlet each: the exact release day of the fix and the KEV due dates. We could not load the CISA catalog page itself today, so the due dates are as The Hacker News reported them.

The four CVEs

The CVE records, published by the CISA coordinator CNA, are the most precise primary source. All four say the same thing about versions: Plex Media Server before 1.43.3.10861 is affected, and 1.43.3.10861 is not.

A fifth issue, CVE-2026-96651 (path traversal, CVSS 3.1 score 6.5), was credited to the same researcher in CISA's coordinated advisory and fixed in the same build. Reporting does not describe it as part of the chain.

Why the scores look low

No single CVE scores higher than 7.2 under CVSS 3.1, and BoredHackerBlog noted that the September records had nothing at 9 or above. The researcher scores the whole chain at 9.8 (network, no privileges, no user interaction), because the early steps get the attacker to the owner level the later steps need. Teams that triage by the highest single score would have filed these as medium. Read together, they are an unauthenticated path to running code.

Sources also word CVE-2026-96654 and CVE-2026-96655 differently: Plex's 19 October update and the researcher's repository each tie the admin token step to a different ID than the CVE records do. The fixed version is the same everywhere. We use the CVE record wording.

How the chain works, in plain language

We will not reproduce the exploit. At a high level, and as Plex, the CVE records and the researcher describe it:

1. An outside request makes the server send a request on the attacker's behalf. The CVE record says any token value is accepted for this step.
2. That reaches internal functions that trust requests coming from the server itself, and the attacker ends up holding the owner's admin token.
3. With owner rights, a transcoder preference is used to get a file written into the Codecs folder.
4. The server loads libraries from that folder without checking signatures, so the planted file runs as the Plex service user.

Two consequences matter for defenders. First, the payload lives in the Codecs folder and in a preference, so it survives a restart. Gizmodo reports that Nick Percoco, Kraken's CSO, noted on X that the payload persists in Codecs and reruns on transcoding, so killing the miner alone does not fix it. Second, the chain depends on the server making outbound requests to a host the attacker controls, which is why egress filtering comes up later in this post.

The crypto mining and proxy campaign

The first public evidence came from BoredHackerBlog, whose author runs a honeypot on an old Plex build. Until 17 October it saw mostly scanning. That morning it saw exploitation "using exploit code from the authors github", in the author's words.

What the honeypot recorded, according to the author's post and later updates:

The Hacker News adds that the shell script fetched a miner named x12345, and that a related subdomain was flagged by Bitsight in August in connection with the AISURU botnet. Plex's own indicator list names myawesomeproxy, mylovelyminer and x12345.

The proxy part is the more worrying one. A home media server sits on a residential IP address. The BoredHackerBlog author suspects residential proxy use, where criminals rent out the victim's connection, and Daily Security Review notes this can be used to reach corporate VPNs and email from an address that looks like a normal home user.

How much do we really know about scale?

Less than the headlines suggest. Daily Security Review says the evidence "rests on a single researcher's honeypot report", and the honeypot author calls their data partial because outbound traffic was blocked by default at first.

Plex's 19 October update is stronger, describing active and wide exploitation. The Hacker News cites Reddit posts from users who found mylovelyminer on their servers, while noting it is not confirmed these came through Plex2Shell. Treat any old build that was reachable from the internet as possibly compromised until checked.

Who is affected

Exposure turns "affected" into "at risk". The researcher notes Plex is "often exposed directly to the internet" on port 32400. A LAN-only server is much harder to reach, though not impossible if another device on the LAN is compromised.

Not the same as earlier Plex issues

Do not mix Plex2Shell up with older Plex CVEs. CVE-2020-5741 was a 2020 Windows flaw that needed an authenticated attacker and was fixed in 1.19.3; CISA added it to KEV in March 2023. Gizmodo also recalls CVE-2025-34158, which Plex handled in 2025 by restricting access for affected builds. Plex2Shell is a separate 2026 chain with its own fix.

What to do now

1. Check the version

The quickest check on the server itself is the identity endpoint, which reports the version:

curl -s http://127.0.0.1:32400/identity
# look for version="1.43.3.10861-..." or later

To compare in a script:

v=$(curl -s http://127.0.0.1:32400/identity | sed -n 's/.*version="\([^"]*\)".*/\1/p')
v=${v%%-*}
if [ "$(printf '%s\n1.43.3.10861\n' "$v" | sort -V | head -1)" = "1.43.3.10861" ]; then
  echo "OK: $v"
else
  echo "UPDATE NEEDED: $v"
fi

Package managers will tell you too:

dpkg-query -W plexmediaserver        # Debian, Ubuntu
rpm -q plexmediaserver               # Fedora, RHEL, CentOS
docker ps --format '{{.Names}}\t{{.Image}}' | grep -i plex
docker exec <container> curl -s http://127.0.0.1:32400/identity

In Plex Web, the server's settings page also shows the version. If you run several servers, check each one; the old Docker box in a closet is the one that gets missed. Some images lack curl; use the settings page instead.

2. Check exposure

ss -ltnp | grep 32400     # is it listening on 0.0.0.0 or only a LAN address?

Then in Plex Web, open Settings, Remote Access and note whether it reports the server as reachable from outside. On the router, look for a manual port forward to port 32400 and for UPnP or NAT-PMP mappings Plex created automatically. From a network that is not yours (a phone off Wi-Fi works), try your public IP and the mapped port:

curl -m 5 -s http://<public-ip>:<public-port>/identity

If that answers, the server is on the internet. Network owners can also subscribe to Shadowserver's free reports, which is where the 49,000 figure came from.

3. Patch

Follow Plex's advisory for your platform:

1. Windows and macOS: install the update from the server's update prompt or download the current build from Plex.
2. Ubuntu or Debian: download the current .deb and install it with sudo dpkg -i plexmediaserver_*.deb. Plex's advisory example shows an old file name, so check the version in the file name you actually downloaded.
3. Fedora or CentOS: sudo dnf install ./plexmediaserver-*.rpm.
4. NAS: Plex warns the vendor app store may not have the build yet; download the package for your device and install it manually.
5. Docker: follow the pms-docker README. Pull the current image and recreate the container rather than restarting the old one, then recheck the version with the identity endpoint.
6. NVIDIA Shield: install pending updates from the Google Play Store.

Restart and confirm the version is 1.43.3.10861 or later before you move on.

4. Look for compromise

Patching closes the door but does not evict anyone. Plex's 19 October update lists what to look for. On Linux:

# Processes started by the Plex server
pid=$(pgrep -f "Plex Media Server" | head -1)
pstree -ap "$pid"
ps -eo pid,ppid,user,%cpu,cmd --sort=-%cpu | head -15

# Codecs folder (default Linux path; NAS and Docker paths differ)
PMS="/var/lib/plexmediaserver/Library/Application Support/Plex Media Server"
find "$PMS/Codecs" -type f \( -name '*.so' -o -name '*.dll' \) -newermt 2026-10-16 -ls

# Transcoder options in Preferences.xml
grep -o 'Transcoder[A-Za-z0-9]*Options="[^"]*"' "$PMS/Preferences.xml"

# Outbound connections from Plex
ss -tnp | grep -i plex

Signs of trouble, from Plex's list: processes named like myawesomeproxy, mylovelyminer or x12345; unfamiliar .so or .dll files in Codecs; connections to proxystream.st; and high CPU while nothing is playing. Also check DNS or firewall logs for proxystream.st and the IPs in the table above. Indicators change, so a clean result is not proof.

5. If you find something

Plex recommends, and we agree:

1. Rebuild from a clean install rather than deleting files one by one.
2. Clear the Codecs folder; Plex downloads legitimate codecs again.
3. Check Preferences.xml for transcoder options you did not set.
4. Sign out of all devices and change your Plex password.
5. Turn off Remote Access if you do not need it.

The attacker ran code as the Plex user, so rotate any credentials that user could read, such as SSH keys or cloud sync tokens.

Remote access settings worth changing

Most people enable Remote Access once and forget it. After Plex2Shell, three changes are worth making:

1. Turn it off if nobody streams from outside. Plex itself lists this in its post-compromise advice.
2. Close what the router opened. Delete any manual port forward to 32400 and turn off UPnP on the router if you do not need it for anything else. A setting in Plex does not remove a forward you created by hand.
3. Put a VPN in front. The researcher's repository recommends keeping the server off the open internet and behind a VPN or other access controls. A WireGuard or mesh VPN lets family members stream without a public port.

Also review who has owner or admin rights on the server, and keep the list of IP addresses allowed without authentication empty unless you have a specific old device that needs it.

What would have helped

Practices any team can use

Read chains, not scores. The four CVEs were medium and high on their own. A rule that escalates any set of CVEs fixed in the same release when one is unauthenticated and one leads to code execution would have flagged these in September, weeks before the exploit went public.

Patch on the vendor advisory, not the CVE. Plex's warning came on 1 September and the fix in early August. Owners who acted on the advisory were patched about six weeks before the proof of concept.

Treat home and edge servers as servers. A media server in an office or on a NAS is internet-facing software with a plugin system and a transcoder. Put it in the asset list with an owner and an update method. Our guide to finding affected products fast shows the inventory side.

Turn on updates where they exist, and schedule them where they do not. Windows and macOS servers can auto-update. Linux, Docker and NAS installs need a cron job, a container update tool or a calendar reminder.

Limit egress. The chain needs the server to make outbound requests to the attacker. The BoredHackerBlog honeypot blocked outbound traffic by default and had to change that to capture payloads. A media server rarely needs to talk to arbitrary hosts; allowing only what Plex needs is a real control.

Watch CPU and new processes. A miner on a media server shows up as sustained CPU with nothing playing. Simple alerting on that would catch this campaign and the next one.

The pattern is the same one we saw with edge device zero days this month: internet-facing appliances, a fix that exists, and a gap between fix and install that attackers measure in days.

Where Safeguard fits

Plex Media Server is a proprietary application that most people install directly on a home server or NAS. Safeguard does not scan home networks, check router port forwards, or watch a running server for miners. It would not have prevented this incident, and most home users do not need it for this. Where it does help is for teams that build and ship container images or appliances:

• Finding where a component lives. SBOM and dependency scanning covers repos, container images and SBOM files (safeguard scan --dir ., --image <name>, --sbom <file>, JSON results under ./output). The platform shows which projects contain a given component and version. If you build your own media or lab images, scan them and check whether a Plex package appears; whether a scanner matches it to these CVEs depends on how the advisory data names the package, so verify rather than assume.
• Holding old versions back. Policies and gates evaluated in the platform can block an image that still carries a known exploited version.
• Doing the fix work with approval. The Safeguard CLI assistant edits code and runs commands with your approval: bumping an image tag in a compose file, pulling, recreating the container and rerunning a version check. Its /permissions modes run from Ask to Strict. Autonomous remediation can open fix PRs; it is off by default.

Zero-Day Discovery and Gold

Zero-Day Discovery looks for previously unknown flaws before a CVE exists, in an agentic mode and a deterministic scanner mode, and issues findings as SGZ advisories before they reach public CVE databases. It covers seven package ecosystems. Plex Media Server is a closed source application outside those ecosystems, and Plex2Shell was found and reported by an independent researcher.

Gold Open Source (gold.safeguard.sh, free, no login) is searchable CVE intelligence with CVSS, EPSS, KEV status, affected and fixed versions and a recommended safe version, plus a free read API and a CI gate GitHub Action. It is built around open source components. Do not assume it lists a proprietary media server; for Plex, the vendor advisory and the CVE records are the source of truth.

Gold Registry (registry.safeguard.sh, paid) provides hardened drop-in components and container images held to zero exploitable critical or high CVEs, SLSA L3 or higher, Sigstore-signed, with evidence pages; an artifact loses its badge on regression. It does not ship Plex, and we are not claiming it had a fixed build. The habit it supports is the one that mattered here: take patched, signed components from a curated source and rebuild fast when a fix lands.

Common mistakes

• Restarting the old container. If the image still holds an old build, a restart changes nothing. Pull, recreate, then check the version.
• Trusting the NAS app store. Plex warns it can lag. Check the version after every update.
• Killing the miner and moving on. The payload sits in Codecs and a preference and comes back on the next transcode, per Plex's guidance and Gizmodo's report.
• Turning off Remote Access in Plex but leaving the router forward. Close both.
• Judging by a single CVSS score. The highest individual 3.1 score was 7.2. The chain is a 9.8 by the researcher's scoring.
• Treating "patched" as "clean". A server patched on 20 October may have been compromised on 17 October.

FAQ

Which version fixes Plex2Shell?

Plex Media Server 1.43.3.10861 and later. The CVE records, CISA's coordinated advisory and Plex's 19 October update all name that build. Plex's earlier 1 September post says 1.43.3; make sure you are on 10861 or later, not an earlier 1.43.3 build such as 10828.

Is Plex2Shell being exploited?

Yes. BoredHackerBlog recorded attacks on a honeypot from 17 October, Plex says the flaws are being "actively and widely exploited", and CISA added all four CVEs to KEV on 20 October. How many real servers were hit is not public.

Do I need Remote Access turned on to be at risk?

The chain starts with a network request to the server, so what matters is whether port 32400 (or the mapped port) is reachable by an attacker. Remote Access is the usual way that happens. A LAN-only server is much less exposed but should still be patched.

Why did CISA give two different due dates?

According to The Hacker News, CVE-2026-96654 and CVE-2026-96656 are due 23 October and the two SSRF flaws on 3 November. CISA's catalog page did not load for us today, so check it directly for the current dates.

Is this the flaw behind the LastPass breach?

No. Gizmodo recalls that the LastPass attackers reportedly used vulnerable media software on an engineer's home computer, which an Ars Technica source identified as Plex, though neither company has publicly confirmed it. Whatever that was, it predates Plex2Shell, a new 2026 chain.

My server is patched. Do I still need to check it?

Yes, if it was reachable from the internet on an old build at any point since 16 October. Run the process, Codecs and Preferences.xml checks above, and rebuild if anything looks wrong.

Does a Docker container limit the damage?

It limits what the attacker can see on the host, but the attacker still controls the container, its network access and anything mounted into it, such as your media library or config. Treat it as compromised and recreate it from a current image.

Fix it without waiting for upstream

In incidents like this one, most of the risk sits in two gaps. The first is the time between a fix being published and that fix actually running in your production builds. The second, and worse, is the time before any fix exists at all, while a maintainer works out a patch and a release schedule. Waiting through both gaps is a habit, not a requirement. Safeguard gives teams three ways to close them.

1. Autonomous remediation: pull requests, not tickets

When a fixed version exists, Safeguard's Griffin models open a tested, policy gated pull request that moves the affected dependency to the safe version. You can run it on one repository or in bulk across every project that carries the vulnerable version. Remediation covers eight categories, including dependencies, licenses, security posture and findings. Reachability analysis ranks the vulnerable code paths your application actually calls first, so the first pull requests you merge are the ones that matter most. Autonomous remediation ships switched off, with every category set to Manual, so your team decides how much runs on its own and what still needs a human approval.

2. Gold Open Source: the safe version in seconds, free

gold.safeguard.sh is free and needs no login. Search any CVE or package to see affected and fixed versions, CVSS, EPSS, CISA KEV status and a recommended safe version, or use the "Am I affected?" checker. The same data is available through a free read API, README status badges and RSS threat feeds. The safeguard-sh/gold-scan-action GitHub Action can fail a build on a known exploited vulnerability, on any known vulnerability, or never, so a version you have just removed cannot quietly come back in next week's merge.

3. Gold Registry: start from components that are already fixed

registry.safeguard.sh provides hardened, drop in replacements for upstream packages and container images. Every Gold artifact is held continuously to zero exploitable critical or high CVEs, zero malware and a completed license check, with SLSA L3 or higher provenance, a Sigstore signature and a public evidence page you can hand to an auditor. An artifact loses its Gold badge if it regresses. Teams can point their own package directory at the registry so hardened equivalents resolve without changing how developers install anything.

When upstream has no fix yet, or will not ship one, Safeguard first works to get the fix accepted upstream. If the issue is severe or upstream will not move, Safeguard builds a fork, fixes the vulnerability there and publishes a hardened Gold build, so you are not stuck on a maintainer's release schedule. You can also request a hardened, compatibility tested build of a specific package. This fork and patch flow is in early access today, so ask which packages it covers before you plan around it.

One honest limit: when the vulnerable code lives in a vendor appliance, a hosted service or an operating system runtime you do not build yourself, the fix still has to come from that vendor or distribution. The steps above apply to the open source dependencies and container images you build and ship, which is where most teams carry the largest and least tracked share of their exposure.

See how Safeguard would have helped

The CLI demo is a real session fixing a lodash CVE: it reads the finding and advisory, asks before each command, edits package.json, and runs install and tests with approval. For Plex2Shell on a container host, you would use the same loop to ask it to bump the Plex image tag in your compose file, pull, recreate the container and rerun the identity version check, approving each command. The demo does not show this incident.

Click through it at your own pace, or open it full screen.

The desktop app demo shows a CLI session in the conversation list, a request for work on your computer, a folder choice, and Approve or Deny on each command and file edit, ending with an upgrade done and tests passing. Here, the folder would be your home lab or office config repository, and the edits would be the image bump plus the Codecs and process checks above, each one reviewed before it runs.

Click through it at your own pace, or open it full screen.

The mobile demo is a real Android session: work goes to a computer running the CLI and you approve the command on the phone with Allow once, Allow for turn or Deny. With exploitation starting a day after the proof of concept, this is how you would approve a container recreate on a Saturday without a laptop.

Click through it at your own pace, or open it full screen.

To scan the images you build and run, download Safeguard and follow the CLI docs. For the rest of the month, see October 2026 security incidents and what would have helped.

Quick check

Sources

• Plex forum: Important Security Update for Plex Media Server v1.43.2 and earlier (1 September, updated 19 October)
• Plex forum: Plex Media Server release notes, 1.43.3.10828
• CVE-2026-96652 record (CVE Services API)
• CVE-2026-96654 record (CVE Services API)
• CVE-2026-96655 record (CVE Services API)
• CVE-2026-96656 record (CVE Services API)
• CISA coordinated advisory VA-26-266-01 (CSAF)
• CVE-2020-5741 record (CVE Services API)
• Zach Main: Plex2Shell write-up
• plex2shell repository on GitHub
• BoredHackerBlog: Plex vulnerabilities being exploited in the wild
• The Hacker News: Hackers exploit Plex2Shell flaws
• The Hacker News: CISA orders federal agencies to patch exploited Plex2Shell, Siemens and SiteGuard flaws
• Security Affairs: Plex2Shell exploit used to turn vulnerable Plex servers into crypto miners
• Daily Security Review: Plex2Shell exploit chain hits Plex servers a day after PoC release
• Gizmodo: Your Plex server could be mining crypto for hackers if you haven't updated it

Last reviewed: 22 October 2026. This is a developing story; check the linked advisories for the latest status.