The vulnerability allows an attacker to manipulate Envoy’s trust model by injecting headers that modify request handling. This can lead to unauthorized access, request amplification, and denial-of-service conditions within a service mesh.
The following configurations are advised to tackle the attack, simulated with curl, in the description above. 1. Filter possibly malicious headers Any HTTP header can be stripped from a request by using the key "request_headers_to_remove" in the Envoy configuration file (for envoy-openssl 2.6 see: https://www.envoyproxy.io/docs/envoy/v1.8.0/api-v2/api/v2/route/route.proto#envoy-api-field-route-route-request-headers-to-remove ). request_headers_to_remove (string) Specifies a list of HTTP headers that should be removed from each request handled by this virtual host. Example: request_headers_to_remove: ["x-forwarded-for"] will remove the "x-forward-for http" header. This is the resulting log entry: {"start_time":"2025-03-19T12:00:40.213Z", "x_forwarded_for":null} Instead of: {"start_time":"2025-03-19T12:04:50.573Z", "x_forwarded_for":"\u003cscript\u003ealert()\u003c/script\u003e"} 2. Do not trust addresses in the x-forwarded-for header but use Downstream IP address. This is possible with the following configuration (see Example 1: "XFF is ignored" case in https://www.envoyproxy.io/docs/envoy/v1.28.7/configuration/http/http_conn_man/headers#x-forwarded-for:~:text=Example%201%3A%20Envoy%20as%20edge%20proxy%2C%20without%20a%20trusted%20proxy%20in%20front%20of%20it ) xff_num_trusted_hops = 0 (no trusted addresses in XFF) use_remote_address=true (untrusted environments: do not use the x-forwarded-for HTTP header but use downstream real address instead) That is, the existing XFF content (IP addresses) will be preserved, but not taken into account, and the downstream real address is added to the XFF header as a trusted address.