Leaderboard

A "correctly setup" reverse proxy shouldn't have passed along the proxy header the attacker used to claim they were on a local address to the Emby server. I'm not aware of any web scan tool that tests for that vulnerability though. For Nginx which is what I use, the "proxy_set_header X-Real-IP" header setting (not the full command, look up how to setup a reverse proxy elsewhere) will pass along the remote IP to Emby. Without that, Emby will see every remote connection as coming from the local IP address of your reverse proxy. I am assuming that header command will override the attacker's fraudulent header info they used and would have kept the Emby server safe from this attack. You also need to be sure that the reverse proxy is the only way to access your Emby server from the web. If you had a port forward directly to Emby in addition to the reverse proxy the attacker could have gotten in that way.

Exactly - you will note that on compromised systems, the IP logged was 127.0.0.1 - ie localhost. NGINX as a REVERSE PROXY (and any other reverse proxy ) will by design drop the HTTP connection and re-create their own to the backend server. That is the key advantage of them - the proxy creates the connection, not the original client. A transparent proxy WILL forward contents without modifying as an example of what we don't want... So yes, we do actually want the remote IP details, but we don't want it from the header, we want it from the IP layer connection - and this is what X-Real-IP does. This then gets added by NGINX to it's newly created header as the X-Real-IP - otherwise we would just get the reverse proxy source IP address as you say.