They Gave Me $1,000 After I Found Their Entire Student Database Exposed!

A writeup about HTTP method override leading to massive PII exposure.

IMPORTANT: To protect the privacy of the affected organization and individuals, all sensitive information in this writeup has been redacted. This includes company names, domain names, personal details (names, emails, phone numbers), and any other sensitive information. Personal data is replaced with (****) or [REDACTED]. This vulnerability was responsibly disclosed and has been fixed!

Hey there! I’m Anukar, a cybersecurity researcher who loves finding vulnerabilities.

If you’ve been following my security journey, you might remember my previous write-up where I became an admin with just one API call. Well, I’m back with another story that proves my point: always keep Burp Suite running, even when you’re just window shopping XD

The Setup

So there’s this private university offering some pretty interesting paid courses online. I wasn’t even in “hacker mode”, I genuinely just wanted to check out their pricing and course details. You know, like a normal person would.

I landed on their study platform at study.[REDACTED].org, filled out the signup form, and they hit me with a 4-digit OTP verification. Fair enough, right? Security first and all that stuff.

The Discovery

Now here’s where my muscle memory kicked in. While waiting for the OTP, I had Burp Suite running in the background (as one does), and after successfully registering, I started poking around the HTTP history.

That’s when I noticed something interesting.

Okay, cool XD, This checks if a user is already registered during signup!
Makes sense from a UX perspective, nothing suspicious yet.

Curiosity Strikes

But here’s the thing about security researchers: we’re professionally curious. And when I see an API endpoint, I start thinking “What if I just… change the HTTP method?”

So I did what any curious soul would do. I modified the request in Burp Suite:

POST /api/users → GET /api/users

Changed the method from POST to GET, removed the request body, kept the same headers, and sent it off.

What Came Back

The response was shocking:

The endpoint just dumped everything. Names, emails, phone numbers, registration dates, the entire student database! Over 15,000 students, accessible to anyone.

Missing of authentication checks, authorization headers, pagination limits that would at least make it slightly harder. Just pure, unfiltered data leakage.

The Technical Breakdown

This is a textbook case of Broken Access Control (OWASP Top 10 #1) combined with poor HTTP method handling. Let me break it down:

The Vulnerability: Improper Access Control on HTTP Method Override

1. POST /api/users: Protected endpoint for user registration (requires data validation)
2. GET /api/users: Completely unprotected, no authentication, returns EVERYTHING

The developers probably thought: “Well, POST is for creating users, so it needs to be accessible. GET is just for internal use, so we’ll add auth later.”

Spoiler: They did not add auth later.

The Stack

Quick shoutout to the stack (because it matters):

• Frontend: Next.js (React-based)
• Hosting: Vercel
• Architecture: Serverless API routes

The beauty (or horror?) of serverless is that each API route is often its own function. If you forget to add authentication middleware to just ONE route… well, you end up in a blog post like this one XD

Key Takeaways

For Developers:

1. HTTP methods are not security controls: If GET is sensitive, protect it the same way you protect POST.
2. Authentication != Authorization: Even if users are logged in, they shouldn’t access ALL user data.
3. Test your API routes independently: Don’t assume because POST is protected that GET is too.
4. Use proper RBAC (Role-Based Access Control): Separate user endpoints from admin endpoints.
5. Rate limiting and pagination: Even if you mess up, these can minimize damage.

For Bug Bounty Hunters:

1. Method Override Testing is GOLD: Try GET, POST, PUT, PATCH, DELETE, OPTIONS, HEAD on every endpoint.
2. Keep Burp Suite running: Even during “normal” browsing sessions.
3. Check plural endpoints: /api/user vs /api/users often behave differently.
4. Look for Next.js API routes: They’re in /api/* and sometimes have inconsistent auth too.
5. Registration flows are treasure troves: Developers focus on the “happy path” and forget edge cases.

Impact Assessment

Severity: CRITICAL

• Confidentiality: High (15,000+ PII records exposed)
• CVSS Score: ~8.6 (High)

Attack Complexity: Low (literally just change POST to GET)
Privileges Required: Low (just need to create a free account)
User Interaction: None

Final Thoughts

The simplest tests often yield the biggest results.

You don’t always need a crazy exploit chain or some zero-day magic. Sometimes, it’s just about:

• Opening Burp Suite
• Changing POST to GET
• Pressing send

That’s it. That’s the whole vulnerability.

Method based testing should be in every security researcher’s checklist. Before you move on from an endpoint, ask yourself:

• What if I use GET instead of POST?
• What if I use PUT instead of PATCH?
• What if I send DELETE?
• What happens if I use OPTIONS or HEAD?

These simple questions can expose massive security gaps.

Responsible Disclosure

As always, this vulnerability was responsibly disclosed to the affected organization immediately upon discovery. They acknowledged the report, responded promptly, and have since implemented:

• Proper access controls on all API endpoints
• Authentication checks for sensitive data retrieval
• Authorization middleware to ensure users can only access their own data
• Rate limiting and pagination on list endpoints
• Security audit of their entire API surface

The student data is now properly protected, and no evidence of exploitation by malicious actors was found.

The Bounty

For this critical severity finding that exposed 15,000+ students PII, the organization offered a bounty of approximately $1,000 USD (₹90,000 INR).

While any recognition is appreciated, it’s worth noting that bounties don’t always reflect the true severity and potential impact of a vulnerability. This was a complete access control failure exposing massive amounts of sensitive data, but hey, that’s the reality of bug bounty programs sometimes :)

The important thing is that the vulnerability is fixed and students’ data is now secure.

Thanks for reading till here!

If you enjoyed this write-up, do share your Responses below 👇🏻

last but not least, Always keep the Burp Suite running haha!

Anukar
Cybersecurity Researcher

Previous writeup: How I Became Admin With Just One API Call

Disclaimer: All security testing was performed with proper authorization and disclosed responsibly. Never test on systems you don’t have permission to test. All sensitive data, company names, and personal information in this writeup have been redacted.

They Gave Me $1,000 After I Found Their Entire Student Database Exposed! was originally published in InfoSec Write-ups on Medium, where people are continuing the conversation by highlighting and responding to this story.