How I Found a Critical IDOR on a Bug Bounty Program With My Own Tool
A real bug bounty case study: I found a critical GraphQL IDOR with Sentinelle in minutes by exploiting an unprotected mutation vulnerable to account takeover.
I found a critical IDOR on a bug bounty program with my own tool Sentinelle.
Here’s exactly how, step by step.
This is the kind of vulnerability that hides inside GraphQL mutations where almost nobody looks.
The Attack in One Line
A GraphQL mutation accepted a userId passed directly in the request body without verifying that the authenticated user was actually allowed to modify that profile.
Any logged-in user could change another user’s email address and then take over the account through password reset.
Step 1 Sentinelle Detects the GraphQL API
I launched Sentinelle against the authorized scope.
Within seconds, the agent identifies a /graphql endpoint and automatically triggers introspection the standard method used to retrieve the full schema of a GraphQL API.
Result:
fully exposed schema
accessible types
visible queries
all mutations mapped automatically
First red flag: introspection enabled in production is almost always a configuration mistake.
Step 2 A Suspicious Mutation
The agent automatically maps every mutation and its arguments.
One immediately stands out:
mutation updateUserProfile(userId: ID!, email: String, ...)The problem is obvious:
userId is supplied directly by the client.
That is one of the most common IDOR patterns in GraphQL applications.
If the backend does not explicitly re-check authorization on the targeted object, any authenticated user may be able to modify another user’s profile.
Step 3 Proof in a Single Request
I log in with a test account.
Then I retrieve another user’s ID trivially exposed through a public query and fire the mutation:
mutation {
updateUserProfile(
userId: "VICTIM_ID",
email: "attacker@evil.com"
)
}
Response: 200 OK
The victim’s profile is updated successfully.
No authorization check.
None at all.
Step 4 The Real Impact
With this vulnerability, any authenticated user can:
change the email address of any account
trigger a password reset
receive the reset link on the attacker-controlled email
fully take over the account
access private user data
On a large platform, this becomes a massive account takeover risk.
Estimated CVSS: above 9.
What Sentinelle Did Automatically
While I was validating the business impact, Sentinelle had already:
detected GraphQL automatically
confirmed active introspection
mapped every mutation and argument
flagged suspicious
*Idparametersgenerated ready-to-fire testing payloads
What would normally require hours of manual recon and schema review took only minutes.
My role was reduced to:
validating impact
reviewing the report
submitting the finding
The Takeaway
GraphQL mutations are one of the biggest blind spots I currently see in bug bounty programs.
The pattern repeats constantly:
front-end developers freely pass object IDs
backend developers assume authentication middleware is enough
nobody verifies authorization at the mutation level
And that is exactly where IDOR vulnerabilities appear.
The Rule Is Simple
Every mutation that accepts an object identifier (userId, accountId, projectId, etc.) must re-check authorization server-side.
Not just the session.
Authorization on the specific targeted object.
That difference is what separates a secure API from a full account takeover vulnerability.
Did you enjoy this article?
Written by
Chris
Tech builder · Agentic AI & offensive security
A tech-obsessed builder, I'm building Sentinelle — an autonomous offensive-security AI agent. I write here about agentic AI, AI-assisted pentesting, and what I learn shipping offensive tooling.
