0-click Account Takeover via Punycode

A Critical 0-Click ATO, When à ≠ a but Your App Disagrees.

Hi, I'm Saif Eldin. I'm a security researcher and bug bounty hunter who enjoys finding real-world vulnerabilities.

On the First: What's Punycode and How It Can Break Authentication?

Before explaining the attack, let's understand how the Internet actually reads domain names and emails.

The Internet's DNS system only understands basic English characters, what's called ASCII (lettersa-z, numbers, and a few symbols). But today, people all over the world use Unicode, a much bigger set of characters that includes every language and accent (like à, ö, é, or even Arabic and Chinese).

So what happens if you try to register a domain that contains one of these special letters? That's where IDNs (Internationalized Domain Names) come in. An IDN is simply a domain that includes Unicode characters, such as:

tàrget.com
café.com
mỳsite.com

tàrget.com
café.com
mỳsite.com

However, since DNS can't read Unicode directly, the browser converts it into a special ASCII-compatible format called Punycode, a version that starts with xn--. For example: tàrget.com → xn--trget-rqa.com café.com → xn--caf-dma.com

Now here's the problem: many Unicode characters look identical to normal ASCII ones. For example, a and à look almost the same to the human eye, but technically, they're different characters.

Why did This Attack happen?

The attack happens when the website or its database accidentally treats two different email strings as the same value, for example, when MySQL (or some app logic) performs a cast. In that case, the system sees the regular ASCII email and the Punycode version as identical, and that mix-up is exactly what the attacker takes advantage of.

Example:

• saif@target.com
• saif@tàrget.com

If you register with saif@target.com and later try to register saif@tàrget.com, and the site replies "User with this email already exists." That's a strong indicator that the app or database is casting those addresses to the same value. When that happens, if a password reset or any email-related process is triggered using the attacker-controlled Punycode address, it could impact the real saif@target.com account, which is exactly how a 0-click takeover can occur.

Now, let's dive into the attack

Steps To Reproduce:

1- Register a normal ASCII email account, for example, saif@adrixa.com and confirm it.

2- I tried to invite the Punycode emailsaif@adrixà.com To my Org, the App says "User with this email already exists"

3- Go to https://``[target.com/reset-password](http://piwiksandbox.com/reset-password) and submit saif@adrixà.com in the reset form.

4- The system sends a reset link to saif@adrixà.com (attacker receives it). Click the link, set a new password.

5- Log in using the original ASCII email saif@adrixa.com And the new password, you now control the account.

Impact:

This vulnerability is far more dangerous than a standard account takeover. Here's why:

1. Zero Interaction Required:_ The victim never clicks anything, approves anything, or makes any mistake. The attacker silently resets their password and logs in._

2. Bypasses Domain-Based Restrictions: Many platforms restrict registration to specific email domains (e.g., only @company.com users can join). Since the Punycode variant (@còmpany.com) is treated as identical, this whitelist is completely bypassed.

3. Bypasses Email-Based 2FA:_ The attacker never needs to touch the victim's real inbox. After resetting the password, the attacker logs in using the Punycode email + new password. The app treats the Punycode address as identical to the ASCII email at every layer, so the OTP is delivered to the attacker's own inbox. The attacker enters the code and lands directly inside the victim's account. Every security layer, password, OTP, etc…, was fully bypassed using only the attacker's controlled email._

4. Undetectable in Logs:_ The entire attack looks like a normal password reset from the victim's own email._

I reported the issue to the security team. They confirmed the bug, and rewarded me for the finding.

UPDATE: I found the same Vulnerability on target on Bugcrowd

On the Bugcrowd target, after resetting the victim's password, I attempted to log in using the original ASCII email and the new password, the application enforced OTP verification and sent the code to the ASCII email inbox. To bypass this, I instead logged in using the Punycode email and the new password. The OTP arrived directly in the attacker-controlled Punycode inbox, I entered it, and successfully accessed the victim's account.

Follow Me and feel free to ask me for any Questions <3

https://www.linkedin.com/in/0xs3fo/

https://x.com/0xs3fo