I Found an Account Takeover Vulnerability in Sorare Through Google Dorking | by Samadhan Shimple

Sometimes, finding a security vulnerability is not about using advanced tools or running complicated scripts. Sometimes, it starts with a simple Google search and a little curiosity.

This is the story of how I discovered a potentially serious account takeover vulnerability in Sorare while randomly exploring Google search results.

I wasn't expecting much when I started. But what happened next turned out to be one of the most interesting security findings I've experienced.

Let's get into it.

The Beginning: Random Google Dorking

I had been spending quite some time hunting for bugs without getting any interesting results. I was getting frustrated and decided to try something different.

Instead of following my usual reconnaissance methodology, I started experimenting with Google Dorking.

After trying several search queries, I came across this one:

site:example.com inurl:token

The results caught my attention.

Google was showing two interesting types of URLs:

• An email confirmation link belonging to a user.
• A device confirmation link containing a token.

Both URLs appeared to contain authentication-related tokens.

At first, I didn't think much about them. I was just exploring the results to understand what information was publicly indexed.

But these two links were about to lead me somewhere unexpected.

An Unexpected Discovery: Device Confirmation Link

I started with the second search result, which contained a device confirmation endpoint.

When I opened it, the application initially displayed a message indicating that the link was no longer valid.

It then redirected me to a profile settings page.

Here's where things became interesting.

Instead of seeing my own profile, I was looking at another user's account.

Initially, I genuinely thought I was viewing my own account. The application had redirected me to a settings page, and I didn't immediately realize that the account belonged to someone else.

I even changed some profile settings before understanding what had happened.

Once I realized the mistake, I stopped interacting with the account.

This unexpected behavior suggested that the device confirmation flow might have been exposing an existing user's authenticated session.

Unfortunately, I hadn't recorded a proof of concept at that moment.

I logged out and attempted to reproduce the behavior, but the link no longer worked.

I thought I had lost the finding.

However, I wasn't ready to give up yet.

The Second Discovery: Email Confirmation Links

I returned to the first Google search result.

It was an email confirmation link.

I opened it, and, as expected, the application displayed an error indicating that the email address had already been confirmed.

Normally, this would be the end of the investigation.

But something about the authentication flow caught my attention.

I wanted to understand how Sorare handled email confirmation links.

So, before going further, I looked at the account registration process.

Understanding Sorare's Email Confirmation Flow

Based on my observations, the registration process worked roughly like this:

1. A user enters an email address, username, and password.
2. Sorare sends an email confirmation link to the registered email address.
3. The user opens the confirmation link.
4. The application verifies the email address.
5. The user is authenticated and can access their account.

One important detail caught my attention.

The confirmation link did more than simply verify an email address. It also appeared to establish an authenticated session.

This raised an important security question:

What would happen if someone obtained another user's email confirmation link?

If these links could authenticate users without requiring their passwords, an exposed confirmation link could potentially become an account takeover vector.

I decided to investigate further.

Investigating the Expired Confirmation Link

I returned to the email confirmation URL that I had found through Google.

When I opened it, the application responded with an error indicating that the email address had already been confirmed.

At this point, I started examining the URL structure and the behavior of its token parameter.

I noticed something unusual about how the application handled certain token values.

Rather than treating the expired confirmation link as completely unusable, the backend appeared to behave differently when the token was altered.

After investigating this behavior, I found that a modified token could produce a different result from the original expired token.

This was particularly interesting because the application was expected to reject previously used confirmation links.

I then tested the behavior using an account that I had created specifically for security testing.

Testing the Behavior With My Own Account

To understand whether this was limited to the publicly indexed links, I registered a new test account.

After registration, I received a fresh email confirmation link.

I first used the original link and observed its expected behavior.

Then I investigated the token-handling issue using my own test account.

The result was surprising.

The application established an authenticated session without requiring me to enter my account password again.

This confirmed that the issue was not simply an unusual redirect or a misleading error message.

There was a potentially serious problem in the way the email confirmation token was being validated and handled.

I recorded the behavior for my proof of concept.

What Was Actually Wrong?

The main issue appeared to be related to the application's email confirmation and authentication logic.

An email confirmation token should be securely generated, uniquely associated with the intended account, and validated against its server-side state.

Once a confirmation token has been consumed, it should not be possible to reuse it to establish another authenticated session.

In this case, my testing suggested that the application was not consistently enforcing the expected validation behavior.

The unusual token-handling behavior allowed a previously rejected confirmation flow to produce an authenticated session under certain conditions.

This is especially concerning because email confirmation links can act as temporary authentication credentials.

If an attacker obtains a valid or improperly reusable link, the consequences could extend beyond email verification.

Why Is This Vulnerability Dangerous?

The potential impact of this issue is significant.

Consider the following scenario:

An attacker discovers an exposed confirmation link through a search engine, a publicly accessible log, or another source of information disclosure.

If the application incorrectly accepts a previously used or manipulated confirmation token, the attacker may be able to establish an authenticated session without knowing the account password.

Depending on the application's permissions and the affected account, this could expose:

• Personal account information.
• Private user data.
• Account settings.
• Other account-related functionality.
• Any sensitive resources accessible to the authenticated user.

The most concerning part is that the attacker might not need the victim's password.

This makes proper token validation extremely important.

Potential Security Classification

Based on the observed behavior, the issue could be classified as:

• Vulnerability: Authentication Bypass / Account Takeover
• Affected Component: Email Confirmation Flow
• Potential Severity: High to Critical, depending on confirmed exploitability and affected account permissions.
• Related CWE: CWE-640 (Weak Password Recovery Mechanism for Forgotten Password), only if the affected flow is part of password recovery; otherwise, a more appropriate authentication-related classification should be selected after reviewing the implementation.

The exact CWE should depend on the underlying root cause rather than simply the visible impact.

How Should This Be Fixed?

There are several security measures that can help prevent this type of issue.

1. Enforce strict server-side token validation

Every confirmation token should be validated against its original account, purpose, expiration time, and current state.

2. Make tokens single-use

Once a confirmation token has been successfully consumed, it should become permanently invalid.

3. Use cryptographically secure random tokens

Confirmation tokens should have sufficient entropy and should not expose predictable or reversible relationships.

4. Separate email verification from authentication

Email verification should not automatically create an authenticated session unless the application has a carefully designed and securely implemented authentication flow.

5. Prevent search engine indexing

Sensitive confirmation URLs should not be publicly indexed. Appropriate indexing controls should be applied, and previously exposed URLs should be invalidated.

6. Review existing authentication sessions

If a token validation flaw is confirmed, affected tokens and potentially compromised sessions should be invalidated.

Lessons Learned

This finding reminded me of something important about bug bounty hunting.

Not every interesting vulnerability starts with a complicated payload, an automated scanner, or an advanced exploitation technique.

Sometimes, a simple search query can reveal something worth investigating.

More importantly, I learned that authentication-related links deserve special attention during security testing.

Email verification, device confirmation, password reset, and magic login links can all become security-sensitive entry points if their token validation is not implemented correctly.

A link that appears expired should not be trusted as secure until its server-side behavior has been properly verified.

Final Thoughts

What started as random Google Dorking turned into an interesting investigation involving exposed confirmation links and unexpected authentication behavior.

The most surprising part was discovering that a link that appeared to be expired could still lead to unexpected authentication behavior.

This experience reinforced one of my favorite lessons in bug hunting:

Never judge an application's security only by the error message it displays. Understand what the backend is actually doing.

And sometimes, the most interesting bugs are hiding in the places nobody thinks to look.

Happy Hunting!

AI assistance:_ I used an AI-powered grammar and spelling checker to review this article. The ideas, research, technical analysis, and final content are my own._

Have questions or want to share your own workflow? Drop a comment below or connect with me on :

🔗Linkdin: https://www.linkedin.com/company/sam-shield/

🔗Youtube: https://www.youtube.com/@sam_shield-w7l

🔗Medium: https://medium.com/@samadhanshimple