1-Click ATO Via Host Header Injection: Exploiting Password Reset Poisoning.

Summary

1-Click ATO Via Host Header Injection: Exploiting Password Reset Poisoning. “Some of the most impactful vulnerabilities don’t begin with complex exploitation chains. Sometimes, they begin with a single HTTP header”. During a recent bug bounty engagement, I discovered a Host Header Injection vulnerability that, at first glance, looked fairly ordinary. However, after following the application’s password reset workflow from beginning to end, I realized it could be turned into a 1-Click Account Takeover (ATO). The entire attack depended on one thing: The victim clicking a single password reset link. The Discovery. While testing the application’s password recovery feature, I intercepted the password reset request with Burp Suite. One question came to mind: Does the application trust the Host header when generating password reset links? To answer that, I replaced the legitimate host with a domain I controlled or in simple words, with my Burp Collaborator ID. The request was accepted without any validation. At that point, I still didn’t know whether the application would actually use my supplied host. The answer arrived a few seconds later — in the password reset email. The Poisoned Password Reset Email. Instead of generating the legitimate reset URL: https://original.domain.com/Registration.aspx?forgotPwd= the application generated: https://attacker.domain.com/Registration.aspx?forgotPwd= The application had embedded a valid password reset token inside a URL pointing to my server. This wasn’t just a Host Header Injection anymore. It had become Password Reset Poisoning. Turning It Into a 1-Click ATO. A poisoned email alone doesn’t prove impact. The real question was: What happens if the victim clicks the link? To verify this, I configured Burp Collaborator as the attacker-controlled domain. The moment the password reset link was opened, Burp Collaborator received the request. Inside it was the complete password reset token. At this point, the attacker has everything needed. By taking the captured token and simply replacing the hostname with the legitimate one like this: https://original.domain.com/Registration.aspx?forgotPwd=<captured_token> the application accepted the token without question and redirected me to another page to set a new password. I was able to set a new password and authenticate as the victim. The result was a 1-Click Account Takeover. The victim only needed to perform one action: Click the password reset link in their inbox. Get kjulius’s stories in your inbox Join Medium for free to get updates from this writer. Everything else happened under the attacker’s control. 🎉 Report & Payout. The report was ultimately marked Out of Scope under the program’s policy because the program explicitly excludes Email Hyperlink Injection. However, the team acknowledged the demonstrated impact and awarded a 100 CHF bonus for the successful account-takeover chain. The Complete Attack Chain. The exploit was surprisingly straightforward:

• Request a password reset for the victim.
• Replace the Host header with an attacker-controlled domain. - The application generates a poisoned password reset email.
• The victim clicks the email link.
• The password reset token is sent to the attacker’s server.
• The attacker reuses the token on the legitimate password reset endpoint.
• A new password is set.
• The attacker logs in as the victim. One click. One leaked token. One compromised account. Why This Happens. The vulnerability exists because the application constructs absolute password reset URLs using a client-controlled value instead of a trusted server-side hostname. As a result, an attacker controls where the password reset link points, while the application continues to trust the embedded reset token. The application effectively hands the attacker a valid authentication secret. Why This Is So Dangerous. Host Header Injection is often dismissed as a low-impact issue because many applications don’t do anything security-sensitive with the supplied header. This application did. It trusted the manipulated value to generate password reset emails. That single design decision transformed a seemingly minor misconfiguration into a 1-Click Account Takeover. Lessons Learned. Security-sensitive URLs should never be built from user-controlled headers. Applications should:
• Use a server-side configured canonical hostname.
• Reject unexpected Host and forwarded host headers. - Validate allowed hostnames at the web server or reverse proxy.
• Consider binding password reset tokens to the intended origin.
• Monitor for abnormal Host header values in password recovery requests. Final Thoughts. This bug was a reminder that impactful vulnerabilities don’t always require complicated payloads or obscure techniques. Sometimes, all it takes is a single trusted header, a password reset email, and one click from the victim. That combination turned a simple Host Header Injection into a 1-Click Account Takeover — a complete compromise of the password recovery process and, ultimately, the user’s account. Always test password reset functionality thoroughly. Sometimes the smallest assumption leads to the biggest impact. Before You Go. If you enjoyed this article, consider following me for more real-world bug bounty write-ups, vulnerability research, and lessons learned from responsible disclosure. I regularly share practical techniques, interesting findings, and insights from hunting for security flaws that make applications more secure. If this article was helpful, feel free to leave a comments, claps, share it with fellow security researchers, and connect with me — I always enjoy discussing web security, bug bounty, and offensive security. Stay blessed.. peace. 🙏

By kjulius

Original Article