Plex2Shell: Plex exploit chain exploited within a day

On 16 October, researcher Zach Main published a technical write-up and proof-of-concept code for Plex2Shell, a chain of four Plex Media Server vulnerabilities that allows code execution on an exposed server without valid credentials. On the morning of 17 October, a vulnerable Plex honeypot run by another researcher recorded the first real attacks: the attackers installed an XMRig-based cryptocurrency miner and, later, a proxy program.

Fixes have been available since September. If you have not updated yet, especially if your server is reachable from the internet, do it now: SecurityWeek, Security Affairs, Ars Technica and the KISA/KrCERT advisory all agree that updating is the priority.

Timeline

• 27 July: the flaws are reported to Plex;
• 4 August: Plex confirms them and pays a bug bounty;
• early September: fixed versions are released; according to SecurityWeek, on 1 September Plex announced it had already shipped the fixes and asked owners to update;
• 16 October: write-up and PoC are published;
• 17 October: first exploitation observed on the honeypot;
• 20 October: KISA/KrCERT update advisory.

Technical details

The chain uses CVE-2026-96652, CVE-2026-96654, CVE-2026-96655 and CVE-2026-96656. The Korean advisory also lists CVE-2026-96651 in the same update, and Ars Technica confirms that five CVEs were published, one rated 8.6 out of 10. Vulnerability types, according to KISA/KrCERT:

• CVE-2026-96651: path traversal;
• CVE-2026-96652 and CVE-2026-96655: server-side request forgery (SSRF);
• CVE-2026-96654: improper neutralization of encoded URI schemes in a web page;
• CVE-2026-96656: external control of file name or path.

Affected versions: Plex Media Server before 1.43.3.10861. Fixed: 1.43.3.10861 and later.

According to the breakdown reported by Ars Technica, the exploit works in steps: an unauthenticated SSRF, a pivot through the loopback interface, theft of a security token, payload delivery and finally execution. Security Affairs, quoting the original write-up, describes the last step: a transcoding-related setting makes it possible to write a shared library into the codecs folder. The Plex loader does not check the library’s name, execute permission, signature or symbols; since dlopen runs ELF constructors (DT_INIT_ARRAY) before resolving symbols, a second transcode is enough for the folder to be re-enumerated and the code to run as the service user (uid=1000(plex) in the PoC).

The sources say execution is possible “provided the required conditions are met”, without listing them all: in practice the greatest risk concerns servers reachable from outside. The researcher said he relied heavily on a large language model to find and chain the flaws, while making the judgement calls himself.

Matching MITRE ATT&CK techniques (our mapping): T1190 Exploit Public-Facing Application, T1129 Shared Modules, T1496 Resource Hijacking, T1090 Proxy.

What the attackers installed

The information comes from a single honeypot, as the honeypot’s operator points out:

• an XMRig-based cryptocurrency miner;
• later the same day, a program called myawesomeproxy, proxy software that displays a notice saying whoever runs it agrees to their connection being used by others.

The researcher warns that the data is partial: the honeypot did not allow outbound traffic and some payloads were not retrieved. The attackers used the public exploit, possibly modified. The published indicators only cover activity seen on the honeypot; no source estimates how many real servers have been compromised or attributes the attacks.

Why it matters to businesses too

Plex is designed for home use, but it also runs on NAS devices, virtual machines and Docker containers (Security Affairs lists them all among the installations to update): it may therefore sit in a small office or on the home network of a remote worker. The most sensitive point is the proxy: as the researcher writes, a Plex server on a residential IP address is valuable to anyone who wants to reach corporate VPNs and email from addresses that look legitimate and get past reputation and geolocation filters.

For NIS2 entities, a compromised server on the corporate network should be assessed as a possible significant incident, with notification to the national CSIRT (CSIRT Italia in Italy) if the conditions are met. It is also worth reviewing VPN and email logins from unusual residential IPs.

What to do now

1. Inventory: look for Plex Media Server instances on servers, NAS devices, virtual machines and Docker containers, including those installed outside IT processes.
2. Update to 1.43.3.10861 or later; consider automatic updates.
3. Reduce exposure: if possible, restrict Plex to the local network; if it must be reachable, Ars Technica suggests going through a reverse proxy instead of exposing the default port 32400.
4. Hunt for traces, because updating does not remove what has already been installed:
   • unexpected child processes started by the Plex service, especially miners or proxies;
   • unusual CPU usage;
   • unknown files, especially .so libraries, in the Plex codecs folder;
   • outbound connections to unrecognized addresses. File names and infrastructure can change: do not rely only on a fixed list of indicators.
5. If you find traces: isolate the machine, reinstall it from scratch and change the Plex account credentials and those stored on the host.

How ARXDOME helps

On computers and servers with the ARXDOME agent, ARX Sentry collects the inventory of software, processes and ports and checks file integrity in the chosen folders: an undeclared Plex installation or a new library in the codecs folder becomes visible. ARX Watch finds devices without a probe on the network, such as NAS devices, ARX Expose shows which of your company’s services and products are visible from the internet, and ARX Shield lets you isolate a suspicious machine from the network.

Last updated: 20 October 2026