Host Header Injection to Full HTML Email Spoofing

Context & Scope#

During independent security research assessing the iOS mobile application and authentication microservices of a consumer mobile banking and digital payments platform, I investigated the authentication lifecycle, specifically the self-service password recovery flow. Modern mobile clients typically interact with backend REST APIs that dispatch transactional emails through third-party delivery services (e.g., SendGrid, Mailgun, or AWS SES).

The objective was to analyze how the backend constructs transactional email content and whether client-controlled routing headers—such as Host or X-Forwarded-*—were implicitly trusted during the generation of password recovery links. The assessment was performed using non-disruptive, isolated test accounts.

Tools & Setup#

Burp Suite - managing upstream proxy chains, analyzing reverse-proxy header propagation, and crafting Repeater test cases.
Proxyman for iOS - intercepting, decrypting, and inspecting HTTPS traffic generated by the mobile client through an installed root CA certificate.
Claude Opus - assisting in evaluating template breakout edge cases and structuring syntactically valid, cross-client HTML injection payloads.
Postman & cURL - modifying HTTP request headers, verifying header reflection, and automating replay runs.
Custom Mail Interceptor - receiving and inspecting raw MIME structures, headers, and SPF/DKIM/DMARC validation results of dispatched transactional messages.

Technical Walkthrough#

Traffic Interception & Workflow Mapping: Utilizing Proxyman configured as an HTTP/HTTPS proxy on an iOS test device, I initiated the in-app password reset routine. The mobile client dispatched an unauthenticated POST request to /mobile/v2/auth/password-update carrying a JSON body containing only the user's registered email address. The backend responded with HTTP 200 OK and triggered a transactional email containing an account reset token.
Testing Host Header Trust (Link Poisoning): Exporting the intercepted request into Postman, I appended the X-Forwarded-Host header, setting its value to an external domain (attacker-domain.example). In many microservice architectures, reverse proxies forward incoming host headers to backend application servers. Rather than referencing a static, canonical base URL from server-side configuration, the backend application dynamically concatenated the incoming X-Forwarded-Host header into the password reset link:
```
https://attacker-domain.example/mobile/v2/auth/password-update?token=<secure_reset_token>
```

Basic Host Header Injection result in email — Email received with poisoned reset link pointing to the attacker-controlled host

Escalation via Unsanitized HTML Injection: While link poisoning is already a significant threat, inspecting the raw email source revealed an even more critical vulnerability: the value of X-Forwarded-Host was not merely placed inside an HTML anchor attribute—it was reflected directly into the email's HTML body without contextual sanitization or HTML entity encoding.

In Postman, I injected a crafted payload containing HTML markup into the X-Forwarded-Host header. The payload closed the original tag, suppressed surrounding template elements with an HTML comment (<!--), and introduced a custom security alert interface in the target locale:

Injecting raw HTML payload inside X-Forwarded-Host header in Postman — Postman request injecting raw HTML into the X-Forwarded-Host header

Exploitation Impact & Spoofing Verification: The backend processed the request without validation and dispatched the email. Because the message originated from the platform's legitimate transactional mail infrastructure, it cleanly passed SPF, DKIM, and DMARC verification, landing directly in the recipient's primary inbox rather than the spam folder.

The rendered email presented an official-looking corporate communication—complete with corporate branding, fake customer service signatures, GDPR compliance notices, and an attacker-controlled credential harvesting link:

Final spoofed phishing email rendered in the inbox — Rendered email showing successful HTML breakout and legitimate sender authentication

bash

curl 'https://api.target-platform.local/mobile/v2/auth/password-update' \
  -X POST \
  -H 'Host: api.target-platform.local' \
  -H 'Accept: application/json' \
  -H 'User-Agent: MobileClient/3.1.0 (iOS; 17.1)' \
  -H 'Content-Type: application/json' \
  -H 'X-Forwarded-Host: security-alert.local/notice?ref=auth"><div style="font-family:sans-serif;padding:16px;"><h3>Security Notice</h3><p>Suspicious activity detected. Please update your credentials: <a href="https://auth.attacker-domain.example/login">Review Account</a></p></div><!--' \
  --data-raw '{"email":"target.account@example.local"}'

Findings & Severity#

Vector / Indicator	Vulnerability Type	Severity
Unvalidated `X-Forwarded-Host` trusted during email link generation	Host Header Injection	High
Direct reflection of unescaped header content into transactional email template	HTML Injection / Email Spoofing	High

Responsible Disclosure & Takeaways#

The findings were responsibly documented and reported directly to the platform's security team along with reproducible payloads and detailed remediation recommendations. The vendor acknowledged the issue, deployed updates to their reverse proxy to strip unverified client-side forwarding headers, restricted host evaluation to a strict server-side allowlist, and enforced contextual HTML escaping within all email templating engines.

From an application security perspective, this assessment underscores two critical takeaways:

Never trust client-supplied proxy headers: Headers such as X-Forwarded-Host, X-Forwarded-For, and X-Original-URL are untrusted client inputs unless explicitly rewritten and sanitized by edge gateways. Core business logic (such as constructing password reset or verification URLs) must always rely on hardcoded server configurations or strict environment variables.
Contextual output encoding applies everywhere: Sanitization and encoding are not limited to browser-rendered web pages. Any service generating formatted content—including PDF generators, transactional emails, webhook dispatchers, and reporting tools—must treat external inputs as untrusted and enforce contextual output encoding.