This is a take on a somewhat classic Host-header injection attack strategy using a homograph attack to bypass the attempt to prevent such an attack.

The normal strategy is to take some page that will trigger an email containing a link, like a Password Reset page. When you make the request to reset a password, you use your host-header injection techniques. Sometimes this is as easy as just changing the Host: header in the request, though in this case they used the X-Forwarded-Host header. Then when the email is sent it may use the value from the injected Host value as the base-domain for the link it created which can be an attacker controlled domain.

In this situation there seemed to be some check to ensure the header was something that would be allowed. Its unclear what that check was exactly the only examples shown are that evil.com did not work, but auth.tárget.com did work. Note the accented a in the domain. That is important, as the intent is like to limit the host’s to just target.com and its subdomains (I can’t imagine why they’d have a check at all if it was just fixed to auth.target.com instead of just using the fixed value). Unicode characters can get tricky when transforming them, and in some cases that ámight get normalized into A or a, then after that normalization it would pass a check for target.com. At which point is crafts the URL trusting the Host value, still containing the accented character and sends that to the victims email. If the victim clicks the link in the unsolicited password reset (but legitimately sent) the reset token will be leaked to the attacker.