CAPTCHA Bypass Bug on a Bug Bounty Program

بسم الله الرحمن الرحيم الحمد لله، والصلاة والسلام على رسول الله.

Hello everyone, welcome back! 👋

Today we're going to talk about one of my favorite topics: bypass techniques.

These techniques are useful in many security tests — not only for CAPTCHA bypass, but also for 2FA bypass, verification mechanisms, and many other scenarios where an application tries to verify that you're a legitimate user.

So, let's jump in.

Platform Overview

The target was a large and well-known platform that provides AI-powered image and video generation as well as design templates.

While testing the registration flow, I noticed that creating a new account required solving a CAPTCHA.

However, one thing immediately caught my attention.

Instead of integrating a third-party solution such as Google reCAPTCHA or Cloudflare Turnstile, the platform had implemented its own custom CAPTCHA mechanism.

That usually means one thing…

Time to start poking at it. 😄

Why Does the Platform Use CAPTCHA?

CAPTCHA exists for several reasons.

One of the biggest reasons is preventing attackers from automating account creation.

Without CAPTCHA, an attacker could create thousands of accounts using a simple script, leading to problems such as:

Spam account creation
Denial-of-Service (DoS) attacks
Consuming expensive AI resources (image/video generation) at the company's expense

Since AI generation costs real money, protecting the registration endpoint is extremely important.

Initial Testing

The registration request looked like this:

POST /api/account/create
Host: account.target.com
{
  "new_email": "example@gmail.com",
  "password": "P@ssw0rd",
  "captcha": "qwertyuiopasdffXXXXXXXXXX"
}

POST /api/account/create
Host: account.target.com
{
  "new_email": "example@gmail.com",
  "password": "P@ssw0rd",
  "captcha": "qwertyuiopasdffXXXXXXXXXX"
}

As usual, I started trying common bypass techniques.

First attempt:

{
  "new_email": "example@gmail.com",
  "password": "P@ssw0rd",
  "captcha": false
}

{
  "new_email": "example@gmail.com",
  "password": "P@ssw0rd",
  "captcha": false
}

Response: 403 Forbidden

Second attempt:

{
  "new_email": "example@gmail.com",
  "password": "P@ssw0rd",
  "captcha": null
}

{
  "new_email": "example@gmail.com",
  "password": "P@ssw0rd",
  "captcha": null
}

Response: 403 Forbidden

Then I tried several other methods:

"captcha": "true"
"captcha": "false"
"captcha": ["true"]
"captcha": ["random_token"]
"captcha": []
"captcha": [""]

"captcha": "true"
"captcha": "false"
"captcha": ["true"]
"captcha": ["random_token"]
"captcha": []
"captcha": [""]

Every single request returned:

403 Forbidden

403 Forbidden

So far…

The CAPTCHA was doing its job.

Then I tried removing the parameter completely.

{
  "new_email": "example@gmail.com",
  "password": "P@ssw0rd"
}

{
  "new_email": "example@gmail.com",
  "password": "P@ssw0rd"
}

Still…

403 Forbidden

403 Forbidden

At this point I had exhausted most of the common bypass techniques.

Everything failed.

The Random Idea

After trying all of the usual tricks, I stopped thinking about the CAPTCHA itself.

Instead, I asked myself a completely different question.

"What if the email address changes the server's behavior?"

It sounded silly…

But bug bounty has taught me that silly ideas sometimes become valid findings.

So I changed the email from:

user@gmail.com

user@gmail.com

user@RandomDomain.com

user@RandomDomain.com

Clicked Sign Up…

and…

Wait… where's the CAPTCHA? 👀

The application created the account without asking me to solve anything.

That definitely wasn't expected.

Bug Scenario

I repeated the test with several random domains:

user@test.com
user@blabla.com
user@private.com
user@anything.com

user@test.com
user@blabla.com
user@private.com
user@anything.com

Every single one bypassed the CAPTCHA completely.

After more testing, I discovered the root cause.

The server enforced CAPTCHA only for well-known public email providers, such as:

@gmail.com
@outlook.com
@yahoo.com

@gmail.com
@outlook.com
@yahoo.com

But for unknown or arbitrary domains, the CAPTCHA validation was skipped entirely.

As a result, an attacker could simply register accounts using random domains and completely bypass the CAPTCHA protection.

Report Outcome

I quickly reported the issue through HackerOne.

Report closed as Informative

after rereading the program policy, I realized why it was closed as Informative.

The program explicitly stated that vulnerabilities leading only to Denial-of-Service (DoS) were considered out of scope.

So although the bypass was real, it wasn't eligible for a bounty under that program's rules.

Lesson learned:

Always read the policy before getting too excited. 😅

Note

Don't assume every program will treat this the same way.

Some bug bounty programs consider CAPTCHA bypass a valid security issue and may rate it as Low or Medium severity depending on the impact.

Others classify it as out of scope if it only enables spam or resource abuse.

Always check the program's policy before reporting.

Similar Accepted Reports

If you're wondering whether this type of issue is accepted elsewhere, here are several public HackerOne reports involving CAPTCHA bypasses:

https://hackerone.com/reports/210417
https://hackerone.com/reports/246801
https://hackerone.com/reports/206653

Thanks for reading! ^_^

See you in the next write-up! 🚀

Contents