Designing a reverse proxy that survives a Plex SSRF

Designing a reverse proxy that survives a Plex SSRF A server-side request forgery in Plex can be mitigated using a reverse proxy, but it is not a foolproof solution. The vulnerability is exploitable via the /video/:/transcode/universal path parameter by an authenticated user. To enhance security, start by listing the endpoints your users actually call and remove any unnecessary ones at the proxy level.

Denying requests from outside trusted networks to this specific endpoint while allowing it for local clients can maintain playback functionality while blocking external access. Controlling the upstream by implementing egress filtering on the Plex host or container level can limit the potential damage. For Docker deployments, ensure the container has restricted network access to prevent lateral movement.

Account hygiene is crucial as the vulnerability requires authentication. Regularly review and remove unnecessary accounts, and consider disabling account creation without approval. While reverse proxy rules can reduce the attack surface, they do not fix the vulnerability. They only limit one handler and the second hop. If the endpoint is allowed locally, the rules may not apply, and encoded slashes or case differences can defeat naive path rules.

After applying proxy rules, verify from an external network that the endpoint returns a rejection and from the local network that playback still works. Confirm that outbound requests to link-local addresses fail at the host level. Ultimately, patching the vulnerability is the most comprehensive solution.