A simple implementation flaw allowed email verification to be completed without ever opening the verification email.

A few weeks ago, I was browsing LinkedIn looking for freelance opportunities when I came across an AI-powered platform looking for freelancers. The platform looked interesting, so I decided to create an account and see how everything worked.

This wasn’t a bug hunting session. I was simply signing up as a normal user.

That said, I have one habit that’s hard to get rid of.

Whenever I register on a new website, I usually keep Chrome DevTools open and watch the network traffic. It’s something I’ve been doing for years, partly out of curiosity and partly because it helps me understand how an application is built.

Sometimes I don’t find anything interesting.

Sometimes I learn how the application works.

And occasionally… I find something the developers didn’t intend.

This turned out to be one of those occasions.

Responsible Disclosure

Before we dive into the technical details, here’s a quick note.

I responsibly reported this issue to the platform’s security team. The report was acknowledged, and the issue has since been fixed.

To avoid exposing the affected platform, I’ve redacted its name, domain, screenshots, and any other identifying information throughout this article.

Interestingly, while investigating this issue, I also came across another security weakness. That’s a story for another day.

Looking at the Registration Flow

For the registration, I used a temporary email address. I usually do this when trying a new service, especially if I’m not sure whether I’ll continue using it.

Before clicking Sign Up, I opened Chrome DevTools and switched to the Network tab.

More specifically, the Fetch/XHR requests.

Once the registration completed, I started reviewing the requests and responses generated by the application.

Most of the traffic looked exactly as I’d expect.

The registration request returned basic account information, a few status fields, and something else.

The token value was clearly a JWT.

At this point, nothing looked particularly suspicious.

Many modern applications automatically authenticate users immediately after registration, so returning a JWT isn’t unusual. Depending on the application’s architecture, it can be a perfectly valid design choice.

I simply made a mental note of it and continued observing the registration flow.

A few seconds later, the verification email arrived.

Like most verification emails, it contained a button that pointed to a URL similar to this:

https://[REDACTED]/verify-email?token=<JWT>

Again, nothing unusual.

Until I looked a little closer.

The token inside the verification URL looked very familiar.

I went back to the registration response, copied both values, and compared them.

They were exactly the same.

That immediately raised a simple question.

If I already have this token from the registration response, do I actually need the verification email?

The only way to answer that question was to test it.

So I registered another account.

Testing the Hypothesis

Rather than clicking the verification link from the email, I decided to repeat the registration process using another temporary email address.

The goal was simple.

Could I verify the account without ever opening the verification email?

After registering the second account, I watched the registration response again and copied the JWT returned by the API.

This time, I completely ignored the inbox.

Instead, I manually constructed the verification URL using the same format I had seen in the email.

https://[REDACTED]/verify-email?token=<JWT>

I pasted the URL into the browser and pressed Enter.

The account was verified immediately.

At that point, the hypothesis was confirmed.

The verification email wasn’t actually required.

As long as the registration response exposed the same JWT used by the verification endpoint, anyone registering an account already possessed everything needed to verify it.

The email merely contained information the client had already received.

Why This Happened

It’s important to point out that the problem wasn’t JWT itself.

JWT (JSON Web Token) is widely used across modern web applications for authentication and securely transmitting signed information between systems.

Returning a JWT after registration is also not inherently insecure. Many applications automatically sign users in immediately after creating an account.

The issue here was much simpler.

The application reused the same token for two different purposes.

The JWT returned by the registration API was also accepted by the email verification endpoint.

As a result, the verification email stopped being the source of trust.

Instead of proving ownership of the mailbox, the application trusted information that had already been provided during registration.

In other words, email verification became an optional step rather than a security control.

How Email Verification Should Work

The goal of email verification is simple:

Prove that the person creating the account actually has access to the registered email address.

A typical email verification flow looks like this:

Notice where the verification token comes from.

The only intended source of the verification token is the user’s inbox. If someone can’t access the mailbox, they shouldn’t be able to obtain the token, and therefore shouldn’t be able to verify the account.

Now compare that with what happened in this case.

Instead of acting as proof of email ownership, the verification email simply duplicated information that had already been exposed during registration.

Once that happened, the verification process no longer answered its original security question:

“Does this user actually control the registered mailbox?”

Instead, it became:

“Does this user still have the JWT that was already returned during registration?”

Those are two very different security guarantees.

Security Impact

At first glance, this might look like a minor implementation mistake.

After all, the attacker is only verifying their own account.

However, the real issue is the broken trust model.

Once the application accepts a verification token that users already possess, it no longer verifies ownership of the email address.

That can have several consequences depending on how the platform uses verified email addresses.

For example:

• Users can verify accounts without ever accessing the registered mailbox.
• Fake or disposable email addresses become much easier to use.
• Any feature that assumes a verified email belongs to its owner can no longer rely on that assumption.
• Future workflows built on the “verified” status inherit the same broken trust model.

The impact ultimately depends on the application.

Some platforms only use email verification to reduce spam.

Others use it as a prerequisite for password recovery, identity checks, invitations, financial transactions, or access to sensitive features.

Regardless of the specific implementation, the underlying guarantee remains the same:

A verified email address should mean the user has demonstrated ownership of that mailbox.

In this case, that guarantee no longer existed.

Lessons Learned

One thing I enjoy about application security is that interesting findings don’t always come from sophisticated techniques.

This wasn’t the result of automated scanning.

It wasn’t discovered with Burp Suite extensions, custom tooling, or fuzzing.

In fact, the only tools I used were:

• A web browser
• Chrome DevTools
• A temporary email service
• Curiosity

The vulnerability wasn’t hidden behind dozens of requests or a complicated authentication flow.

It was visible in plain sight.

All it took was slowing down, observing the application’s behavior, and asking a simple question:

Do I actually need the verification email?

That question led to a business logic flaw that made email verification optional.

It’s a good reminder that application security isn’t always about finding clever payloads or bypassing complex filters.

Sometimes it’s about understanding what a feature is supposed to achieve, then verifying whether the implementation actually delivers that security guarantee.

Final Thoughts

As developers, we often focus on whether a feature works.

As security researchers, we also need to ask whether it works securely.

In this case, the registration flow appeared to function perfectly.

Users received a verification email.

The verification link worked.

Accounts became verified.

From a functional perspective, everything looked correct.

From a security perspective, however, the email had stopped serving its original purpose. The application trusted a token that had already been exposed during registration, making the inbox irrelevant to the verification process.

This is exactly why business logic vulnerabilities can be so easy to miss.

Nothing crashes.

No error messages appear.

No scanners raise an alert.

The application behaves exactly as expected — until someone asks whether the security assumption behind the feature still holds.

Thanks for reading!

If you’re a developer, I hope this write-up encourages you to look beyond whether a feature works and think about what security guarantee it’s supposed to provide.

And if you’re interested in bug bounty or application security, remember that you don’t always need advanced tools to find meaningful vulnerabilities.

Sometimes, Chrome DevTools, careful observation, and a bit of curiosity are more than enough.

Happy hacking! 🚀