Internet-facing Plex Media Servers running builds older than 1.43.3.10861 are being attacked through a chain of four vulnerabilities. Plex says it has seen widespread attacks since a public proof of concept appeared on October 16; compromised servers have run cryptocurrency miners and proxy software that routes others’ traffic through the owner’s connection. Owners of a server exposed through remote access or a forwarded 32400 port should check its installed version and look for compromise now.
On October 20, CISA placed the arbitrary-file-write flaw CVE-2026-96656 in its KEV catalog. The KEV entry sets an October 23 federal action date and calls for forensic triage. The September Plex security release fixed the server issues, and Plex’s October 19 update connected them to active exploitation. Its warning is blunt: “If your server is older than 1.43.3.10861 and reachable from the internet, assume it may be compromised.”
Four flaws reach the Codecs folder
Plex identifies the chain as unauthenticated server-side request forgery in the player timeline endpoint (CVE-2026-96652), access to internal agent functions over the loopback interface (CVE-2026-96654), disclosure of the server owner’s admin token (CVE-2026-96655), and a file write into the Codecs directory through transcoder preferences (CVE-2026-96656). Together, Plex says, they let an unauthenticated remote attacker run code with the privileges of the Plex Media Server process. That makes internet exposure relevant even though the last flaw, considered alone, requires admin privileges.
The CVE Program record names the preference TranscoderH264Options and describes how its value reaches the encoder’s options on a transcode. It also says the server runs .so files from the Codecs directory at startup without checking a signature, execute bit or symbol. The server process’s access to mounted shares and locally stored credentials shapes the possible damage after execution. The CVE record credits researcher Zach Main.
Plex processes and Codecs files to inspect
Plex tells operators to inspect processes started by Plex Media Server for unfamiliar names, including myawesomeproxy, mylovelyminer and x12345. Look for unfamiliar .so or .dll files in the Plex Codecs folder, outbound connections to proxystream[.]st, and sustained high CPU use when nothing is playing. A miner may be noisy; proxy software can quietly use the same machine and internet connection. Investigate these signs alongside any other unexpected activity on the same host.
Review the machine and the Plex service account’s reach together. Mounted shares and credentials on the host or VM may have been accessible to code running as Plex. CISA marks forensic triage “Yes” for this KEV entry; retain relevant files and process and connection records for investigation before wiping a suspicious server.
Update Plex and rebuild suspect servers
Open Plex Web, go to Settings → General and read the installed server build. Plex identifies 1.43.3.10861 as the first unaffected build; update to that build or newer and verify the version shown afterward. A NAS package manager may lag the vendor release, so use the appropriate Plex package and the NAS manufacturer’s manual-install procedure when needed. For a server that has no reason to be reachable remotely, turn off Settings → Remote Access and remove an unneeded forwarding rule for 32400.
If you find unfamiliar Plex child processes, .so or .dll files in Codecs, proxy connections or idle high CPU, or cannot rule out compromise on an exposed older server, Plex recommends rebuilding from a clean installation without reusing the old Plex data directory. At minimum, Plex says to clear the Codecs folder and inspect Preferences.xml for transcoder options you did not set. Sign out of all devices in Plex account settings, change the Plex password, and assess shares and credentials reachable by the Plex service account. Verify the rebuilt server reports 1.43.3.10861 or newer, and review its new process tree and outbound connections against the indicators you investigated.