Initial Notes
This type of article is, as far as I know, one of the first of its kind. I couldn’t find any article that goes deeply into the technical side of this type of vulnerability.
There have been some vulnerabilities discovered around the same topic in 2026, according to the CVEs I found, which I’ll mention later in the article.
I hope you enjoy reading it! This article is the result of a lot of research, experimentation, and countless attempts , and “hopefully”, none of them were illegal 😅.
How the Idea Came
On October 1st, 2026, I had a rather difficult day. When I got home, I registered for a website using Google OAuth 2.0, which was also offered on the signup page as:
Once I had registered with Google, I realized something interesting about this website.
At one point, when I had tried to register with an email address, the website asked me to enter a verification code that was sent to my Gmail account.
But when using Sign up with Google, the behavior was different: the website set up the account directly based on the email address linked to my Google account, without requiring me to go through the same email verification step, and then asked me to choose a password later.
That made me think:
What if the OAuth provider sets up ordinary accounts without first requiring email verification?
And more importantly:
Could the website end up inheriting the OAuth provider's belief that the linked email address has already been verified if it trusts the provider when registering?
This raised another question.
Could a difference in trust models arise if the OAuth provider permits an application to set up an account using an associated email address without carrying out the application's usual email verification procedure?
For example, might the different verification states be responsible for causing account takeover (ATO), pre-account takeover (Pre-ATO), verification bypasses, or other account-linking problems?
This marked the beginning of my research.
I decided to look at this behavior across a number of different OAuth integrations and applications, with a particular focus on the trust relationship between OAuth identity verification and email verification at the application level.
For this vulnerability class, I use the name:
OAuth Verification Trust Mismatch
For this type of vulnerability to make sure that it can exist, I had to use a real OAuth service provider, such as Discord's service, along with some clients that were, unfortunately, affected by this type of vulnerability.
I won't mention those clients for their privacy, and because testing them without authorization would be illegal. So, never do this yourself and always make sure you have proper authorization before testing.
For your own safety, only test this type of behavior on applications and programs where you have explicit permission to conduct security test
Introduction
OAuth Verification Trust Mismatch (as I call it) is a type of mismatch or misconfiguration caused by a difference in trust between the OAuth service provider and the client application accepting the OAuth authentication.
For example, when the client application verifies an email address received from an OAuth third party without making sure that the account on the vendor's side is also email-verified, an attacker may be able to register an account with an unverified email address on the vendor's side, while the client application incorrectly treats that email address as verified.
This mismatch caused the application to register a verfied email by an attacker side to be accepted as the owner’s is the one created it
An example I found during researching
Note: I tested this using the OAuth authentication service provided by Discord, as Discord is one of the well-known providers that allows the OAuth service to be used without immediate email verification. Instead, for using this service, I verified my phone number, as this was the only attacker-controlled input available to me instead of email verification.
When I was testing this vulnerability (do not do this without permission — don't copy meeee!), I used an application that had both:
- Signup using email + password + email verification
- Signup using Discord
When signing up with a normal email address, the application required an email verification code sent to the Gmail address before allowing me to continue the signup process.
After noticing this behavior, I created a non-email-verified Discord account and only verified the attacker's phone number to use the OAuth service.
When I tried to use this account to sign up on the vulnerable client, the application should have made an API request to Discord's endpoint and checked the JSON response, especially the "verified" field, before creating the account.
It didn't.
Instead, it relied on the wrong assumption:
"If the request came from an OAuth service, of course the user owns the account."
Thanks to Discord's anti-spam system, which flagged my IP because I was creating too many accounts 😅
Comparing Responses
This is only one of the vulnerabilities caused by this misconfiguration, which I refer to as an "OAuth Mismatch", and that allows email verification to be bypassed.
When I applied the same method to a number of applications that use Discord OAuth, I found that the way in which they handled an unverified Discord account varied significantly.
1. Access Denied
Certain applications rejected the OAuth request and stated that the email address associated with the Discord account had not been verified.
This shows that, when the application receives the user's Discord profile from Discord, it checks the verified field. If the field is true, the application treats the email as verified; otherwise, it rejects the authentication or account creation request.
This is an effective approach because the application's OAuth flow enforces the same verification requirement as the standard signup process.
2. Rejected Without an Explanation
Some applications also rejected the OAuth flow without providing any explanation.
Instead, the flow ended with an Unknown Error or redirected me back to the login page.
Although these applications did not explicitly state that the email was unverified, they still prevented the unverified account from completing the authentication process.
3. Accepted, But the Account Remained Unverified
In other cases, the OAuth flow was allowed to proceed even though the email associated with the Discord account had not been verified.
However, the account created on the application's side was also treated as unverified.
In this case, there was no verification bypass. The application simply accepted the Discord identity while preserving the unverified state of the email address.
4. Accepted and Circumvented the Verification Requirement
The most interesting behaviour was observed in applications that normally require email verification as part of their standard signup process.
Through Discord OAuth, these applications accepted the unverified Discord account and proceeded to create the account without requiring email verification.
This can occur when email verification is enforced only during the application's standard signup process, while the OAuth registration flow follows a separate path and fails to enforce the same requirement.
In other words, OAuth provides an alternative account-creation path that bypasses a security requirement imposed by the standard registration process.
The key point is that the issue does not lie in Discord treating the email as verified. Instead, the application fails to consistently enforce its own email-verification requirement across its different authentication flows.
Why does this mismatch rise?
Actually, this mismatch did not originate from only one side,the vendor or the client. It resulted from the interaction between both systems.
In the example I discussed earlier, the vulnerability arose because of a mismatch between Discord's OAuth behavior and how the client application handled the authentication result.
- Discord's side: Discord allowed an account to be created without email verification and allowed its OAuth service to be used after verifying the account through an attacker-controlled phone number. On its own, this behavior is not necessarily a vulnerability.
- Client's side: The client application trusted the OAuth authentication result without independently checking whether the Discord account's email address was actually verified. Again, this behavior alone is not necessarily a vulnerability.
However, when these two behaviors were combined, they created a security boundary mismatch. The client treated the Discord-authenticated account as sufficiently verified, even though the email identity behind that account had never been verified causing email verification bypass
Neither behavior alone created the vulnerability. The vulnerability emerged from the way these two independent behaviors interacted.
What Mistakes Can Each Side Make?
The vulnerabilities aren't always due to one error; they can occur when the assumptions of the OAuth provider and the client application do not agree.
Vendor-Side Mistakes
1. Setting up accounts without email verification
The provider enables users to set up and make use of an account without them having to first verify ownership of the email address linked to it.
2. Permitting OAuth authentication without enforcing the required identity guarantees
The provider permits an account to authenticate using OAuth even though important identity attributes, such as email ownership, have not necessarily been verified.
3. Not clearly revealing the account's actual verification status
It is not clearly stated by the provider whether or not an account's email address has actually been verified, which makes it hard for client applications to tell the difference between verified and unverified identities.
Client-Side Mistakes
1. Using an OAuth service without understanding its security model
The application connects with an OAuth provider even though it does not fully understand the guarantees that the provider makes regarding account ownership, email verification, and identity.
2. Placing complete faith in the email provided by the provider
The application regards the email address provided by the OAuth provider as conclusive evidence of ownership without first verifying that the email has actually been verified.
3. Using an OAuth provider which does not meet the application's security requirements
For instance, an application which needs to verify email ownership should not automatically depend on a service that permits accounts to be created without email verification.
4. Checking automatically each account that has been authenticated through OAuth
The account is regarded as verified as soon as successful OAuth authentication has taken place, even if the provider does not mandate email verification at the time of creating the account.
5. Disregarding the provider's OAuth security recommendations
The application does not follow the security requirements and recommendations provided by the OAuth vendor when implementing its authentication process.
From all of these examples, we can notice that vulnerabilities arising from this type of OAuth integration are mostly caused by the client application using the service incorrectly.
We can't simply put the blame on the vendor. The vendor is providing a service with a specific security model and specific guarantees. If you use that service correctly and understand what it actually guarantees, you should be safe.
But if you use it incorrectly or make assumptions about what the provider guarantees, then the problem is on your side.
If you use the service correctly, you're safe. If you don't, it's time to revise your implementation.
How Far Can Its Impact Go?
The most primary vulnerabilities that can arise from this mismatch include:
1. Email Change Through OAuth Linking
When linking an OAuth account, some applications may replace the user's primary email address with the email returned by the OAuth provider.
This behavior can be safe when the provider verifies ownership of the email address. However, if the application does not check the email_verified status and treats the returned email as proof of ownership, an attacker may be able to replace the victim's email with an address they control.
If the application trusts the new email for password resets or account recovery, this behavior could allow the attacker to take control of the victim's account.
2. Unauthorized OAuth Account Linking
Another possible scenario occurs when an application allows users to link an OAuth account as an additional authentication method.
If the application does not properly validate the provider's email_verified status, an attacker-controlled OAuth identity may be linked to an existing account based on an unverified email address.
If the application subsequently allows authentication through the linked OAuth identity without requiring additional proof of account ownership, the attacker may gain access to the existing account without changing its primary email address.
3. Pre-Account Takeovers
A Pre-Account Takeover can arise from the same mismatch we discussed earlier.
In this case, the attacker can potentially reserve or establish control over the victim's future account without ever needing access to the victim's inbox.
If the attacker is able to use an OAuth provider that does not require email verification, while the client application does not check whether the provided email has actually been verified, the application may accept that email as legitimate and create or associate an account with it without asking for additional verification.
This means that when the real owner later tries to register using the same email address, the account may already exist or may already be associated with an authentication method controlled by the attacker.
Note: Pre-Account Takeovers are often not considered a vulnerability by themselves because the legitimate owner may still be able to recover the account through an email verification step, remove the attacker's OAuth connection, reset the password, or request account deletion.
4. Blind Linking
Blind linking occurs when the victim already possesses a regular account that has been registered and verified using their email address.
For example, suppose that the victim has already signed up using victim@example.com but has never connected their Discord account.
If a person later logs in through an OAuth provider using an account that is linked to the same email address, the application might detect that the email address is already associated with an existing account.
Rather than rejecting the login or requiring the user to clearly prove that they are the owner of the existing account, the application can automatically assume that the OAuth account belongs to the same user and treat it as an additional login method.
The Flow
- The victim already possesses a verified account.
- The victim has never before connected an OAuth account.
- The login process using OAuth is carried out with the same email address.
- It locates an account that is already established with that email address.
- Rather than asking for extra verification, it automatically links the OAuth account.
- The OAuth account is now available as a further method of signing in to the existing account.
If the OAuth provider permits unverified email addresses and the application does not verify the provider's email_verified status, an attacker may be able to associate their OAuth identity with the victim's existing account
.
What is important is that the application is not simply agreeing to the OAuth login; instead, it automatically turns it into a trusted login method for an existing account.
5. Privilege Escalation
In some cases, this vulnerability can have a greater impact when chained with other authentication or account-linking flaws.
For example, some websites have pre-registered accounts for specific purposes, such as:
support@domain.comadmin@domain.comsecurity@domain.com
These accounts may have unique privileges, allowing them to access internal dashboards, support tools, or other sensitive resources.
If the application is vulnerable to blind OAuth account linking, an attacker may be able to exploit this behavior to link an OAuth identity under their control to one of these existing accounts.
For example, some OAuth providers, such as Discord, allow users to authenticate without verifying their email addresses first. If the application trusts the email returned by the provider without checking its email_verified status, it may automatically link the attacker's OAuth identity to an existing account.
If that account has elevated privileges, the attacker may be able to gain access to those privileges through the linked OAuth identity, potentially turning an account-linking flaw into a privilege escalation vulnerability.
Another possible scenario involves applications that grant special privileges to accounts based on their email domain.
For example, an application may automatically grant additional permissions to accounts registered with its primary domain, @domain.com.
Although the application may normally require email verification before granting these permissions, an attacker could potentially bypass this requirement if the application trusts an OAuth provider's email claim without properly checking its verification status.
As a result, an attacker-controlled OAuth identity could be treated as a verified organizational account and receive privileges that should only be available to legitimate members of the organization.
However, this depends on how the application handles email verification and assigns privileges. Simply using an email address from a specific domain does not prove ownership of that address or membership in the organization.
More?
Of course, there are more possible scenarios that can arise from the same underlying issue: a trust mismatch.
The impact depends on the authentication flow implemented by the client application, and it can potentially lead to scenarios such as:
2FA Bypass
Some websites may treat authentication through a trusted OAuth provider, such as Google, Facebook, Discord, X, or Spotify, as sufficient proof of account ownership.
As a result, the application may allow the user to log in without requiring its own 2FA challenge, even when 2FA is enabled on the account.
If the application incorrectly assumes that a successful OAuth login is sufficient to satisfy its own MFA requirements, this behavior could potentially lead to an MFA bypass.
OAuth Account Re-registration
Consider a user who previously registered an account with an OAuth provider that did not require email verification. The user later deletes that OAuth account, while the client application retains the account originally linked to that identity.
If another person subsequently registers a new OAuth account using the same email address, and the application relies on the email address alone to recognize the previously linked account, it may incorrectly associate the new OAuth identity with the existing client account.
This could potentially allow the new identity to access an account that was originally linked to someone else, depending on how the application handles deleted identities and account linking.
Of course, there are many other possible scenarios that cannot easily be covered in a single article. Since this is fundamentally a business logic issue, the resulting impact depends heavily on how the developer designed the application's authentication and account-management flows.
Now after i gave you some technical things about the topic , we will transfer to some real-world-examples and at the end we will return to the technicality again
Real-World Examples
Now, we will talk about some real-world examples, and at the end, we will return to the technical details again.
Nhost: CVE-2026-41574 — Account Takeover via OAuth Email Verification Bypass
Target: Nhost
Researcher: dbarrosop
Source: https://github.com/nhost/nhost/security/advisories/GHSA-6g38-8j4p-j3pr
Severity: Critical (9.3)
Overview
When the researcher investigated Nhost, a SaaS platform which provides backend services for developers, they came across an interesting issue in its OAuth authentication process.
Nhost supports a number of OAuth providers, one of which is Discord. The interesting point is that Discord is able to return an email address even if that email has not been verified.
With respect to Discord OAuth, you shouldn't automatically trust each email that you receive; rather, before regardting the email as verified, you have to verify whether Discord itself considers it verified.
How is this done? By making an API request to Discord in order to get the information about the authenticated user:
GET /api/users/@me HTTP/1.1
Host: discord.com
Authorization: Bearer YOUR_ACCESS_TOKEN
And the response might look something like this:
{
"id": "123456789012345678",
"email": "user@example.com",
"verified": true
}
What's important in this case is the verified field.
So, if the statement is true then Discord regards the email as having been verified; if it is false then Discord has not verified the email.
Simple enough, right?
Hmm, it seems that the situation wasn't that simple for Nhost.
The Developer's Assumption
Instead of using Discord's verification status, the Nhost Discord adapter used this piece of code:
EmailVerified: userProfile.Email != "",
Let's examine exactly what this does.
It verifies whether the email field is empty; and if an email address is present, it then marks the email as verified.
That's all there is to it—the entire check.
Well, if an email is there it must be verified, since how could someone possibly use OAuth without having an email, then?
Apart from that, the fact that an email address is there doesn't mean that ownership of it has been verified.
Discord is capable of returning an email address even when the verified status is false. However, Nhost was not at all checking that field and it was in effect saying:
Yes, the email exists; in that case it's verified!
There's where the trouble began.
How has this turned into an account takeover?
Suppose that the victim already has an account on an application which is built using Nhost and has registered with victim@example.com.
Currently, an attacker is in control of a Discord account which gives the same email address, even though Discord has not verified that email.
Whenever the attacker logs in via Discord, the provider adapter used by Nhost regards the email as verified just because the email field is not blank.
Nhost's account-linking logic can subsequently match the email to the victim's existing account, link the attacker's Discord identity with it, and then assign a session to the matched account. (blind linking)
That is to say, the attacker can get access to the victim's account without the victim being required to approve the linking process.
The entire situation could occur since the code verified that the email existed rather than checking that it had been verified.
The adapter should have used the verified value returned by Discord in order to preserve Discord's real verification status.
The necessary verification requirements should also have been enforced by the account-linking logic before an external identity was linked to an existing account.
[REDACTED] — Account Takeover via Multiple OAuth Layers
Overview
When I was carrying out my research into this kind of vulnerability, I wanted to find out if it could have any real-world impact rather than just treating it as another interesting piece of code.
Therefore, I began to look for websites that used OAuth via Discord, Spotify, or some other service where an email address could be returned even if it had not been verified.
I was able to spot a target which I shall call REDACTED.com.
REDACTED.com had another domain which could be used as an OAuth provider when logging into the main website; for this example, we will refer to the second domain as REDACTED_2.com.
That is to say, users could authenticate themselves at REDACTED_2.com, which functioned as an extra identity provider for REDACTED.com.
That's where things became interesting.
The email verification bypass flaw existed in the way that REDACTED_2.com implemented Discord OAuth. Rather than checking whether the email provided by Discord was actually verified, the application accepted the email as part of the authentication process without properly enforcing the verification status.
That allowed me to set up an account with REDACTED_2.com by using a Discord account which had an unverified email address, the website accepting this and letting the registration process move on.
By this stage, the problem was already there on REDACTED_2.com, but I wanted to find out whether the impact ended there or whether it could affect another application that trusted it.
As we mentioned earlier, REDACTED.com used REDACTED_2.com as an OAuth provider. This added another level of authentication to the situation.
Rather than carrying out the authentication itself through Discord, REDACTED.com used REDACTED_2.com to authenticate the user and then provided the resulting identity.
The fact that REDACTED_2.com accepted accounts set up using the vulnerable Discord OAuth process without properly verifying the email addresses associated with them allowed me to use that account to log in to REDACTED.com as well.
we learned something new here:
When using an OAuth service, keep in mind that the service itself may rely on another OAuth provider. If that provider is implemented incorrectly, the resulting vulnerability could affect your website as well.
Better Auth — CVE-2026-53516: Account Takeover via OAuth Auto-Linking to an Unverified Pre-Registered Email
Target: Better Auth
Researcher: avrmeduard
Source: https://github.com/advisories/GHSA-g38m-r43w-p2q7
Severity: High (8.3)
It serves as a good example of blind linking in order to show how OAuth account linking can result in serious security problems.
Better Auth is an npm package which deals with authentication, OAuth, session management, and other features.
There was a vulnerability which allowed Better Auth to automatically associate an OAuth identity with an existing local account that had the same email address, even if the email address on the local account had not been verified.
Imagine an attacker setting up an account by using an email address and a password. The account is at this stage unverified. Usually, the user has to verify the email by means of a magic link or a verification code; however, if an application supports OAuth account linking, it might also make use of the provider's verified-email claim when deciding whether to trust that email.
The vulnerability was caused by two related issues:
- Blind linking: The programme automatically connected an OAuth identity with an account that had the same email address.
- Insufficient verification of the local account: The logic used for linking checked if the OAuth provider regarded the email as verified, but it did not at the same time require the email associated with the existing local account to be verified.
Overview
The account is set up without verification when the attacker uses an email address and a password.
The application was committing a serious error.
When a user accessed the system via an OAuth provider, Better Auth had the facility to associate that provider with an existing account that had the same email address.
The procedure examined the provider's email_verified claim but did not verify whether the emailVerified field of the existing local account was also set to true.
This created the following attack scenario:
- The attacker sets up an account with the victim's email address and a password.
2. The victim then logs in through an OAuth provider which verifies that the email address has been verified.
- Better Auth automatically connects the victim's OAuth identity with the attacker's previously registered account.
- When the account is linked, the email address associated with the local account is verified.
- The attacker will be able to continue accessing the account which has now been verified using the password that they first set. As a result, an account takeover occurs before the victim makes their first OAuth login.
the attacker has already obtained a password-based login to an account linked with the victim's email address, and the flawed linking procedure then associates the victim's OAuth identity with that account.
The Pentester Checklist
Now that we know these kinds of vulnerabilities can exist in the wild, we can put together a few points to look out for the next time you test an application's OAuth functionality.
1. Check the Available Providers
When checking the available OAuth providers on a website, take note of which providers the client supports for login.
For example, you might see options such as:
- Continue with Google
- Continue with Facebook
- Continue with Discord
- And others...
This is an important starting point because different providers may handle email verification differently. For example, some providers may allow accounts with unverified email addresses to use their OAuth services.
This can be a good starting point when looking for email-verification and account-linking vulnerabilities.
2. Check Whether the Client Uses OAuth Correctly
This is a significant part of the process because incorrect OAuth implementation is often the main factor behind these vulnerabilities.
Check whether the application correctly handles the information returned by the provider, especially the email address and its verification status.
Do not assume that receiving an email address from an OAuth provider automatically proves that the address has been verified.
3. Check for Edge Cases
Look for edge cases in how the application handles OAuth authentication and account linking.
For example:
- Does logging in through OAuth automatically mark the local account's email as verified?
- What happens when an account with the same email address already exists?
- Can an OAuth identity be linked to an existing account without the required verification?
- Does the application handle verified and unverified provider emails differently?
These cases can help reveal situations where the application's trust in an OAuth provider does not match its own account-verification requirements.
What should developers do?
When developers are carrying out an implementation of OAuth, they should take a number of factors into account if they are to avoid security problems in their own applications.
1. Carefully select your OAuth providers
People who are preparing the applications should know which OAuth providers they are using; if a provider has inadequate security measures or is one that is known to have vulnerabilities, then the risks will increase.
Just because you are using a well-known provider does not mean that the integration is secure, the application had to verify the authentication response and deal with the returned information correctly.
2. Look at the provider's documentation
A mistake that certain developers might commit is to think that all OAuth providers function in the same way.
Since different providers offer different fields, carry out email verification in different ways, or have special requirements as to the information they need from users, developers should base their understanding on the actual commitments of each provider rather than making assumptions about the way another provider operates.
3. check the status of your email verification
Before developers examine an email that an OAuth provider has marked as verified, they should make sure that the provider offers a reliable verification status and deal with it properly.
It is possible for some providers to let users log in even when their email addresses have not been verified, and security problems might occur if the application assumes that all the emails obtained through OAuth have been verified.
The email should not be taken as having been verified automatically unless the provider supplies a reliable verification status.
4. It is not necessary to connect the accounts when the emails match
One still has to be careful about linking a verified email address returned by an OAuth provider to an existing local account.
When linking accounts the programme should adhere to a secure procedure and must ask the user to prove that they own the account before allowing another identity to be linked to it.
The fact that two email addresses match should not be regarded as enough evidence to prove that the accounts belong to the same person.
5. OAuth verification must be separated from local account verification
The fact that a provider has confirmed the email address is verified does not mean that the application should automatically alter the verification status of an existing local account.
Developers must deal with these states specifically and have to ensure that the account-linking process does not fail to meet the application's own security requirements.
This is especially important when applications offer both email-and-password registration and OAuth login.
Conclusion
Finally, these types of vulnerabilities are considered business logic vulnerabilities, so their scenarios are countless. Every application can have its own unique issues, making this type of vulnerability particularly interesting.
When dealing with these types of vulnerabilities, always make sure to check the tiniest details. Make sure everything works as expected, and never give up testing when you find even the smallest gap.
thanks for reading this article , hope you enjoyed :)
for contact , click here