Mastering Race Conditions: Two Methods for Bypassing Email Verification

Email verification serves as a fundamental security boundary. By ensuring an account is tied to a verified identity, applications protect sensitive functions like user invitations, data sharing, and organization management from malicious spoofing.

During audits of two different target applications, I discovered that this core trust assumption can be completely broken using Race Conditions. By forcing the applications to handle state transitions concurrently, I successfully bypassed email confirmation mechanisms in two unique ways.

Method 1: Bypassing the Invitation Restriction via Concurrent State Change

The Logic

The first target allowed users to sign up without immediate email verification. However, to invite external users to an organization, verification became mandatory. Furthermore, to prevent attackers from using fake identities, the application blocked users from changing their email address while an active invitation was pending.

The security state machine looked like this:

1. Is the current email verified? If yes, allow the invitation to send.

2. Lock the email address from being modified until the invite is resolved.

By exploiting a race condition, I aimed to slip a new, unverified email address into the system exactly as the invitation process validated the old, verified one.

The Exploitation

Using Burp Suite, I captured two distinct requests from a pre-verified attacker account:

• Request A: Send an invitation to a target victim.

• Request B: Change the account's email address to a fake, unverified domain ([email protected]).

I staged Request A once and duplicated Request B multiple times into a single Burp Suite Request Group. Using Parallel Burst execution, I fired them simultaneously.

The Result

The server processed the requests within the same microsecond window. The application successfully validated that the account was verified when Request A initiated, but before the application locked the email field, Request B overwrote the profile data. The victim received an invitation originating from an unverified, entirely fabricated email address.

Method 2: Token Misalignment via Concurrent Confirmation Manipulation

The Logic

The second target utilized a standard email migration flow: when a user updates their email, the platform generates a unique token sent to the new inbox. Clicking that link fires a confirmation request to finalize the change.

The vulnerability existed because the backend verified the token's validity independently of checking whether the user had initiated a secondary email change request at the exact same moment.

The Exploitation

1. Prepare a Legitimate Token: I updated my verified account email to a second email address that I controlled ([email protected]). The system dispatched a valid verification token to my inbox.

2. Intercept the Confirmation: I captured the confirmation request containing the valid token in Burp Suite, but did not execute it yet.

3. Stage the Spoof: I went back to the profile settings and prepared a standard email change request, but this time inputted a target or spoofed address ([email protected]).

4. Execute the Race: I grouped the Email Confirm request (holding the token for the owned email) and the Email Change request (targeting the fake email) together and executed them concurrently in parallel.

The Result

Because the requests were executed simultaneously, a classic Time-of-Check to Time-of-Use (TOCTOU) bug occurred. The application processed the email change to [email protected] right as the confirmation routine checked the database. The token validator confirmed the token was valid, but applied the "verified" state to the newly modified active record ([email protected]).

As a result, the account was instantly bound and verified to an email address I had no actual ownership of.

Summary of Impact

Both findings demonstrate that relying on step-by-step linear logic on the backend is inherently dangerous if requests are handled asynchronously. By abusing these race windows, an attacker can:

• Spoof corporate identities to execute high-credibility internal phishing.

• Hijack accounts or register under domain spaces they do not control.

• Completely circumvent business logic designed to enforce identity verification.

For more write-ups on logical flaws and race condition techniques, follow me on Twitter: @siratsami71.