Designing a reverse proxy that survives a Plex SSRF

Most guidance for CVE-2026-96655 ends at "upgrade to 1.43.3.10861". That is correct and sufficient for many owners. For the ones who cannot upgrade on the day the advisory lands, the question becomes what a proxy layer can realistically stop.

The flaw is a server-side request forgery reachable by an authenticated user through the /video/:/transcode/universal path parameter. The server fetches a location the client nominates. A proxy cannot judge intent, but it can constrain which paths exist and which upstreams are addressable.

Start with path inventory, not blocklists

A useful exercise before writing any rule: list the endpoints your users actually call. Plex clients talk to a relatively stable set of transcoding and metadata routes. Anything that no client needs is a candidate for removal at the proxy. Blocking only the exact parameter pattern from the advisory is fragile, because parameter shapes change between client versions while the endpoint stays the same.

A blunt but effective rule denies requests to /video/:/transcode/universal from sources outside your trusted networks, and passes them through for local clients only. This keeps household playback working while removing remote reachability of the vulnerable handler.

Constrain the upstream, not just the caller

The interesting part of an SSRF is the second hop. Even if you must allow remote access to the transcoding endpoint, you can shrink the blast radius by controlling what the Plex host is allowed to reach. Egress filtering at the host or container level, denying RFC1918 ranges other than the specific media storage host, and denying link-local addresses outright, breaks the most common exploitation targets.

Docker deployments deserve specific attention. A container on a bridge network can usually reach its own host and any sibling container. If the media server shares a compose network with a database or admin panel, the SSRF has a short path to something valuable.

Authenticate deliberately

The vulnerability requires authentication, so account hygiene directly changes your exposure. Two practical measures: review every shared account and remove the ones that no longer serve a purpose, and confirm whether your deployment allows account creation without approval. A server with three accounts has a much smaller authenticated-user population than one with forty.

Consider whether remote users need transcoding at all. Many deployments use direct play for remote clients, which means the transcoding endpoint could be restricted to the local network with no user-visible loss.

What the proxy cannot do

Reverse proxy rules do not fix the vulnerability. They reduce reachability of one handler and limit the second hop. If an attacker already has local network access and the endpoint is allowed locally, the rules may not apply.

Also, path matching depends on normalisation. Encoded slashes, duplicate slashes and case differences have historically defeated naive path rules on multiple proxy products. Test your rule with encoded variants before trusting it, and prefer a default-deny posture where only known paths are forwarded.

Verification steps

After applying proxy rules, verify from an external network that the endpoint returns a rejection rather than a Plex response. Then verify from the local network that playback still works. Confirm at the host that outbound requests to link-local addresses fail. Finally, still schedule the upgrade: compensating controls buy time, not immunity.

2026's disclosure record makes the point repeatedly. The Plex advisory ties CVE-2026-96655 to CVE-2026-96652, CVE-2026-96654 and CVE-2026-96656, three defects in the same request-handling surface. Proxy rules that block one path will not cover the others. Patching covers all four.

References

• Plex security advisory for Media Server 1.43.2 and earlier
• CISA Known Exploited Vulnerabilities entry for CVE-2026-96655
• NVD record for CVE-2026-96655