Hi everyone 👋, I hope you're having a great day. In this post, I'll show how I found a vulnerability in a self-hosted bug bounty program that allowed me to bypass email verification and manipulate AI credits just by modifying a request — and interestingly, this was discovered within the first minute of testing the program.

🔍 Discovery

While testing the registration functionality, I started by creating a normal account and intercepting the request using Burp Suite.

Within the first minute of interacting with the program, I sent a normal registration request and carefully checked the response, and I noticed something interesting:

The server was returning the full user object, including sensitive fields like:

  • verified
  • aiCreditsPaid
  • aiCreditsUsed
  • assetsKeyworded
  • assetsKeywordedPaid
  • settings

This immediately indicated a possible Mass Assignment issue.

So instead of guessing parameters, I simply:

  • Took the response
  • Reused it in the request
  • Started modifying values

💥 Exploitation

1. Email Verification Bypass

In the original flow, accounts should not be verified until email confirmation.

But I changed this:

"verified": false

➡️ to:

"verified": true

The server accepted it without validation.

✅ Result: Account created as verified instantly (no email needed)

2. AI Credits Manipulation

Then I tested credit-related fields:

"aiCreditsPaid": 50,
"aiCreditsUsed": 0

➡️ Modified to:

"aiCreditsPaid": 5322222,
"aiCreditsUsed": 0

✅ Result: I received massive AI credits without any payment

3. Additional Manipulatable Fields

I also confirmed that multiple internal values could be controlled:

{
  "verified": true,
  "aiCreditsPaid": 5322222,
  "aiCreditsUsed": 0,
  "assetsKeyworded": 33,
  "assetsKeywordedPaid": 50
}

All of these were accepted directly from the client.

⚠️ Impact

This vulnerability has multiple critical impacts:

  • ❌ Full Bypass email verification
  • 💰 Unlimited AI credits without payment
  • 🔓 Full control over user internal attributes
  • 🤖 Abuse of platform features at scale
  • 📉 Financial loss for the company

Because the server trusts user input, an attacker can fully control their account state.

🧠 Root Cause

  • Trusting client-side input
  • No validation on sensitive fields
  • Direct binding of request → user object (Mass Assignment)

📌 Conclusion

This was a simple but powerful vulnerability that I discovered very quickly during testing.

Instead of fuzzing blindly, I:

  • Sent a normal request
  • Analyzed the response
  • Reused it
  • Modified sensitive fields

This approach made it easy to discover multiple issues at once.

✨ Takeaway

Always check server responses carefully — sometimes they expose everything you need.

Mass Assignment bugs can completely break application logic if not handled properly.

Let's connect on x and linkedin

https://www.linkedin.com/in/ali-shreif-819224328/

https://x.com/sh3rif0x

Discovered by @sh3rif0x 🚀

#bugbounty #cybersecurity #websecurity #apisecurity #massassignment #hackerone #infosec #securityresearch #bughunter #authbypass