Hi Stape Team,
we’ve recently discovered a Host Header Injection issue on our sGTM endpoint hosted via Stape. When sending requests with a modified Host header (e.g. via Burp Suite), the response reflects the injected host value. This could potentially allow:
- cache poisoning
- redirect-based phishing
- or header-based trust abuse
CriticalityJustification
“”‘Host header injection allows attackers to manipulate server behavior, potentially redirecting users to malicious sites or polluting application caches. The impact depends on the application’s reliance on the Host header. If the application uses the header for critical functions like session management or authorization, the impact is significantly higher. Exploitability is generally high as it often requires only manipulating an HTTP request header. Exposure depends on the application’s accessibility – publicly facing applications have higher exposure. The business context is crucial; a vulnerability in a public-facing e-commerce site poses a much greater risk than one in an internal application.
“”
Suggested FIX
"’- Configure the application to not trust the Host header value for further functionality. If this is not possible, then implement a whitelist of trusted domains that can be used in the Host header.
"
- Is Stape’s reverse proxy layer expected to validate or rewrite the Host header?
- What’s your recommended best practice to restrict or sanitize the
Hostheader value on a Stape-hosted container? - Should we implement a host allowlist check inside GTM Server (e.g. in a middleware or custom template)?
Any official guidance, hardening tips, or existing fixes would be appreciated. We’re trying to close this finding for a recent security audit.
