The Day an Email Broke Single Sign-On
2 min read
September 28, 2025
Table of contents
Hi everyone,
In this edition I want to share something a bit different, focused on authentication in web applications. It’s a neat trick that I think is worth testing in your own engagements. Hope you enjoy it!
The story
When dealing with authentication and single sign-on (SSO) systems, email addresses are often used as unique identifiers. This makes sense because they are easy to validate and naturally unique for most users. However, using emails as identifiers without carefully designing how they are handled can introduce unexpected risks.
One common issue arises when applications allow changes to critical identifiers like email addresses without proper validation. If login logic is tied to these identifiers, attackers can abuse the process to disrupt normal access or even escalate their privileges.
A couple of months ago I found a real example of this during a security review of an OAuth2 single sign-on system. At first glance everything seemed fine. Companies, or tenants, could register wallets for their users, and each tenant could add multiple accounts. Emails were treated as unique across the platform. If one tenant had already registered an email, no other tenant could use the same one. The system would reject the attempt and show an error saying the user already existed.
The protection looked solid, but there was a flaw. The restriction only applied at registration time. When editing an account, the platform allowed the email to be changed to one that was already in use. No validation checks were performed.
Because the system was based on SSO, the login flow became much more dangerous. The platform always prioritized the account that had been created first when deciding where to log a user in.
This design opened the door to two serious attack scenarios.
- Denial of Service (DoS)
An attacker could create an account before the victim and later change its email to match the victim’s. From that moment on, the login flow would always resolve to the attacker’s tenant. The victim would be locked out of their real account and unable to access their company environment. - Privilege Escalation
Within a single tenant, the same logic allowed privilege escalation. If an attacker registered a normal account before an administrator was created, they could later update their email to the administrator’s. Since the older account took precedence, every login would grant the attacker administrator rights instead of regular user privileges.
A small oversight in email validation combined with the “first account wins” rule in the SSO logic turned into a powerful vulnerability.
A small story, but I think it’s a useful tip that often goes untested and can lead to serious trouble. See you in the next one!
Stay sharp,
Ruben
Chapters
Previous Issue
Next Issue
