Plex Media Server October 2026 KEV response: update, review exposure and recover compromised hosts

What it is

Status as of 25 October 2026. CISA added CVE-2026-96652, CVE-2026-96654, CVE-2026-96655 and CVE-2026-96656 to KEV on 20 October 2026. They involve server-side request forgery, internal-function access and file-writing weaknesses. Plex's security notice began on 1 September; its 19 October 2026 update confirms active exploitation and identifies 1.43.3.10861 as the unaffected server baseline. Re-check that notice, later releases and each KEV action before closing remediation.

Why it matters

The server hosts the affected components. Updating a television or desktop playback application is not evidence that the server changed. Plex advises treating an older internet-reachable server as potentially compromised. A successful update must therefore be recorded separately from the integrity assessment.

CISA lists different due dates: 23 October 2026 for CVE-2026-96654 and CVE-2026-96656, and 3 November 2026 for CVE-2026-96652 and CVE-2026-96655. Do not assign the whole group the latest date. Record applicable directive requirements separately from the organization's incident and patch priorities.

How to apply

• Record server evidence. In Plex Web, inspect Settings > General and capture the complete server version. List every machine, NAS package and container running a server. Establish which instance each client reaches before assessing its status.
• Reduce exposure. Turn off unnecessary Remote Access. Plex documents both automatic router mappings through UPnP or NAT-PMP and manual port forwarding. As a containment check, inspect those mappings, reverse proxies and host firewalls for the owned server; remove unwanted exposure and verify from an approved external location. Do not disable firewalls to troubleshoot an unpatched installation.
• Install the correct server package. Obtain a current platform-specific package through Plex's official distribution route. For a Debian package, the documented installation form is sudo dpkg -i ./plexmediaserver.deb, replacing the example filename with the actual downloaded package. Follow the vendor's separate NAS or container procedure. After restarting the server, verify that the running version reaches the security baseline or a later supported release.
• Investigate published signs. Plex identifies unfamiliar binaries in the Codecs directory, unexpected child processes and connections to proxystream.st. Preserve process, network and file evidence before cleanup. Compare observations with the dated advisory and investigate unexplained activity rather than assuming a filename match is conclusive.
• Recover and secure the account. Where compromise cannot be ruled out, Plex recommends a clean rebuild and account-wide sign-out with a password change. Review what the service could access. From a clean device, inspect Authorized Devices and remove unknown entries. Plex documents that removed devices must sign in again to re-register. Enable account two-factor authentication and store its recovery codes somewhere accessible without the authenticator device.
• Verify the restored service. Document the new server version, deliberate remote-access configuration and account-device list. Test normal playback and required integrations. Keep an incident record linking retained evidence, recovery decisions and any service credentials rotated because they were exposed.

Pitfalls

A NAS package-manager delay is not evidence that an old package is safe. Do not reconnect a rebuilt server to a suspected contaminated data directory without review. Two-factor authentication strengthens future sign-ins; it does not establish server integrity. Plex also warns that switching between Plex Home members does not generate an additional two-factor prompt. Missing indicators alone cannot prove that an exposed host was never compromised.