The $0 IDOR That Was Worth More Than a $12,500 P1

In 2024, a researcher reported a GraphQL bug on HackerOne. By adding aliases to a single mutation, one authenticated request could force the backend to repeat an expensive operation — about 8 seconds per alias — until the server timed out. No data was stolen. No account was taken over. A server got slow, then recovered.

The bounty: $12,500.

Last year, another researcher reported an IDOR. By changing one user ID in an API request and keeping their own token, they could read any user's profile — email, gender, bio, location. The entire user base, one cURL request at a time. CVSS 7.1. High impact.

The company had known about it since December 2021. It was triaged as Informative back then. It was still exploitable in March 2025. The researcher's report was closed as a duplicate.

The bounty: $0.

Two bugs. One restarted a server for a few minutes and paid the price of a car. The other exposed every user's personal data for over three years and paid nothing.

The bounty math is broken. And IDORs are where it breaks the loudest.

This piece is not an argument against paying well for DoS bugs. It's an argument for understanding why the bugs that actually hurt users — IDORs, access control flaws, business logic issues — are the ones that get downgraded, dismissed, and left to rot. And what to do about it.

Both bugs above are real, public, disclosed cases. I'm using them because the contrast is not a thought experiment. It's a pattern.

The $12,500 server restart

The GraphQL case was reported by @hellokbit. The affected mutation was verifyAccountRecoveryPhoneNumber, part of the account recovery phone verification flow.

The mechanism was simple. GraphQL lets you alias the same field multiple times in one request:

verify1: verifyAccountRecoveryPhoneNumber(input: {...})
verify2: verifyAccountRecoveryPhoneNumber(input: {...})
verify3: verifyAccountRecoveryPhoneNumber(input: {...})

verify1: verifyAccountRecoveryPhoneNumber(input: {...})
verify2: verifyAccountRecoveryPhoneNumber(input: {...})
verify3: verifyAccountRecoveryPhoneNumber(input: {...})

Each alias made the backend run the verification logic again. Each run took about 8 seconds. Stack enough aliases and a single request pushed execution past the timeout. A few concurrent requests produced 500s and unstable behavior under almost no load.

No botnet. No flood of traffic. Just a few expensive GraphQL requests.

It was a clean, well-argued report. The impact was real: authenticated DoS on a recovery flow, degrading availability for legitimate users trying to secure their accounts. It deserved to be paid.

But notice what made it easy to pay: the impact was visible in one request. You send it, the server struggles, you show the timeout. A triager can reproduce the harm in seconds. The story writes itself.

That visibility is exactly what IDORs lack. And it's the root of the problem.

The $0 IDOR

This case was reported by a researcher named Abin and written up publicly. The target was an API endpoint that returned user profile data:

GET https://api.example.com/users/23659xxxx
Authorization: Bearer <attacker_token>

GET https://api.example.com/users/23659xxxx
Authorization: Bearer <attacker_token>

The application had what looked like solid validation. Changing the ID in the UI returned no data. Intercepting the request in Burp and changing the ID returned a 401 Unauthorized. On the surface, both client-side and server-side checks seemed to be in place.

But the researcher copied the request as a cURL command, kept their own valid Bearer token, and changed only the user ID:

curl https://api.example.com/users/23659xxx \
  -H "Authorization: Bearer <attacker_token>"

curl https://api.example.com/users/23659xxx \
  -H "Authorization: Bearer <attacker_token>"

The response came back with another user's full profile — email, gender, bio, location.

The flaw was specific: authorization was checked against the presence of a valid token, not against ownership of the resource being requested. Any authenticated user could read any other user's data by swapping the ID.

The researcher confirmed it across multiple accounts and even wrote a bash script to enumerate IDs:

#!/bin/bash
BASE_URL="https://api.example.com/users/23659xxxx"
JWT="your_jwt_token_here"
for i in {1000..9999}; do
  USER_ID="${BASE_URL}${i}"
  curl -s -H "Authorization: Bearer $JWT" -X GET "$USER_ID"
  sleep 10
done

#!/bin/bash
BASE_URL="https://api.example.com/users/23659xxxx"
JWT="your_jwt_token_here"
for i in {1000..9999}; do
  USER_ID="${BASE_URL}${i}"
  curl -s -H "Authorization: Bearer $JWT" -X GET "$USER_ID"
  sleep 10
done

CVSS v3.1 scored it 7.1 — High. The impact was unambiguous: mass PII disclosure across the entire user base, with clear paths to account takeover, phishing, identity theft, and regulatory exposure under GDPR, CCPA, and HIPAA.

Then came the response from the program:

Thank you for your report! Unfortunately, this was submitted previously by another researcher… For transparency, I am including an excerpt here from the original report:

Title: IDOR leads to api key and other sensitive information disclosure State: Informative Date: Sat, 18 Dec 2021 08:49:19 GMT

Read that twice. The same bug was reported in December 2021 and triaged as Informative. It sat there, exploitable, for over three years. When it was reported again in March 2025 — still live, still leaking — it was closed as a duplicate. The researcher got nothing.

The original report's title even mentioned "api key and other sensitive information disclosure." This wasn't a low-impact finding misjudged as low. It was a high-impact finding downgraded to Informative and then forgotten.

That's not a one-off triage mistake. That's a pattern.

Reference

• GraphQL mutation aliasing DoS (verifyAccountRecoveryPhoneNumber) — reported by @hellokbit on HackerOne, bounty $12,500. Analyzed in: "How GraphQL Mutation Aliasing Led to a $12,500 DoS Bug."
• IDOR on /users/{id} returning full profile PII — reported by Abin, March 7, 2025; closed as duplicate of an original report from December 18, 2021 (triaged Informative). CVSS v3.1: 7.1 (High). Writeup: medium.com/@abinsecurityresearcher/bac-idor-300-2-500-a694f1739ce7.