July 8, 2026

How a Trusted Header Turned Into an Open Redirect in Telekom’s System

Host Header Injection → Open Redirect

By m0ro23

1 min read

Host Header Injection → Open Redirect

Target

example.telekom.com

Vulnerability Type

Host Header Injection leading to Open Redirect

Summary

The app trusts the X-Forwarded-Host header blindly and uses it to build redirect URLs. If you swap that header for an attacker-controlled domain, the server happily redirects users there instead of staying on the real site. Since the redirect comes from a legit Telekom domain, it's a solid setup for phishing.

Steps to Reproduce

  1. Intercept a request to the target with a proxy (Burp, etc).
  2. Add this header to the request:
X-Forwarded-Host: evil.com
  1. Send the request.
  2. Check the response. You get a 302 redirect, and the Location header points straight to evil.com.

Proof of Concept

Request:

GET / HTTP/2
Host: example.telekom.com
X-Forwarded-Host: evil.com

Response:

HTTP/2 302 Found
Location: https://evil.com/login?next=https://evil.com/

Impact

  • Open redirect abusing a trusted domain, which makes phishing links look legit at first glance.
  • Users get redirected from a domain they trust to an attacker-controlled page.
  • Sets up credential harvesting, since victims think they're still on the real login flow.
  • Can be chained with other issues, like OAuth misconfigurations or password reset poisoning, to escalate further.

Root Cause

The server pulls the host value straight from X-Forwarded-Host, a header fully controlled by the client, and uses it directly to construct redirect URLs without validating it against a list of trusted domains.

Fix Recommendations

  • Stop using X-Forwarded-Host to build redirect URLs.
  • Enforce a whitelist of allowed domains for any redirect logic.
  • Make sure redirects always resolve to a trusted, hardcoded domain, never a header value.