Akwaaba! guys. Read my previous blog on Android Intent Redirection, an easy $2000 for mobile app hackers. At times, a simple path tweak can leak ALL user PII. Let me tell you about a vulnerability I discovered simply by observing.

‼️ Disclaimer: I've changed specific details about the application in this write-up for confidentiality. Even the screenshots shown are from a different, similar application that doesn't have a bug bounty program — they're only used for illustration.

The Program

This app offers two ways to sign up: the standard email/password route or a quick OAuth sign-up using Google or GitHub.

If you choose email/password, the app puts you in a "pending" state. You're sent a verification link and blocked from the dashboard until you click it. However, the OAuth flow is different, it assumes the third-party provider has already done the legwork, so it bypasses the verification step entirely and drops you straight into the account.

OAuth Account Fusion

Imagine you create an account with user@gmail.com using a password but never bother to verify it. Later, you come back and click "Sign up with Google" using that same email. The application sees the matching email and automatically fuses the two accounts into one. Now, you can log in using either method.

The problem is that by "fusing" these accounts, the application effectively grants "verified" status to the original email/password account without the user ever having to click that verification link. It assumes that because you own the Google account, you must own the original unverified account, a shortcut that often leads to some serious security oversights.

The Vulnerability

While testing the account fusion logic, I found a clean way to bypass the verification requirement entirely.

If you create an account with an email and password but leave it in that "unverified" pending state, the app is just waiting for a confirmation. The second you (or anyone else) use that same email to sign up via OAuth, the app fuses the two. The "unverified" status of the email/password account is simply overwritten by the "trusted" status of the OAuth provider. No more verification link required.

This GraphQL exploit made me $1,500 just because I read the JavaScript

The Exploit

To test this, I started by acting as the attacker. I went to the standard registration page and signed up using a target email (let's call it victim@gmail.com) and a password I controlled.

As expected, the application did its job, it hit me with a "Verify your account" wall and blocked me from the dashboard. I have the credentials, but I don't have the access.

With the first browser still stuck on the "Verify your email" screen, I opened a private tab and went through the Sign up with Google flow using that same email address.

As expected, the OAuth process completed and dropped me straight into the dashboard.

I switched back to the tab that had been sitting on the "Verify account" message and simply hit refresh. Instead of asking for a code, the page reloaded and redirected me immediately to the dashboard.

The application had seen the successful OAuth login, decided the email was now "trusted," and instantly upgraded the pending session in my other browser.

Read this different Email Verification Bypass blog which led to a $1,500 payout.

Impact of this Attack

This works in a pre-takeover scenario where an attacker can sign up an account with anyone's email address. With verification pending, they only need to wait out for the victim to sign up via OAuth. They can now access the same dashboard through the email-password channel whereas the victim would be using the OAuth channel.

Payment

I got paid $500 for this finding mostly because they focused on the fact that this is a Pre-Account Takeover.

Rate Limit Bypass is actually easy when you know which header to use.

Thanks for reading this, if you have any questions, you can DM me on X @tinopreter. Connect with me on LinkedIn Clement Osei-Somuah.