Install any skill in seconds. Free to start, no credit card required.
Get Started Free →elementalsouls/hunt-fintech-graphql
Hunt fintech-specific GraphQL vulnerabilities: money-movement mutations (transfers, redemptions, withdrawals, card top-ups), ledger/balance/portfolio query IDOR, decimal-precision and rounding abuse, idempotency-key bypass enabling double-spend, KYC/PII field-level authorization gaps, and admin-override mutations reachable via mass assignment. Distinct from hunt-graphql, which owns generic GraphQL discovery and IDOR/mutation methodology — this skill owns the delta introduced when a GraphQL layer
Passed 19 of 25 test cases with the skill, and 12 of 25 without it.
and 7 more in the full report
8 fixed11 passed either way5 still failing1 broke
Tokens, turns and time describe resource use, not a dollar price.
One of 8 test cases the skill fixed. Same model, same prompt, with and without the skill.
Before setting up multi-threaded parallel HTTP requests, how can an auditor use native GraphQL query features within a single HTTP POST request to test if a mutation serializes writes? Provide a sample GraphQL payload.
| Checked | Without skill | With skill |
|---|---|---|
| Include multiple aliased mutation calls in a single GraphQL query payload | Passed | Passed |
| Observe if multiple aliased calls succeed against a single-use reward resource | Missed | Passed |
The instructions your model reads when the skill loads.
Generic GraphQL bugs (IDOR, mass assignment, introspection, batching abuse — see hunt-graphql)
still apply here, but the blast radius changes completely: a resolver bug in a SaaS app leaks
data, the same class of bug in a ledger mutation moves money. Three properties make fintech
GraphQL backends a distinct hunting surface:
transferFunds, redeemRewards, withdrawToBank) can trigger multiple
ledger writes (debit + credit + fee) that must be atomic. GraphQL's flexible input shape and
alias batching make it easy to desynchronize those writes.Float, String, custom
Decimal/Money scalar). How the resolver parses and rounds that value is exploitable surface
in its own right — this barely exists in non-financial GraphQL APIs.User or Account
types commonly expose ssnLast4, routingNumber, kycStatus, governmentIdUrl, or
linkedBankAccount alongside displayName and email — one missing field-level authorization
check on a type used everywhere in the schema fans out to every query that touches it.URL / schema naming patterns (in addition to hunt-graphql's generic /graphql list):
/graphql/ledger
/graphql/payments
/api/wallet/graphql
/internal/ledger-graphql
/banking/graphql
Field/type names worth grepping schema introspection or JS bundles for:
balance, availableBalance, pendingBalance, ledgerEntry, ledgerEntries
transferFunds, withdraw, redeem, topUp, reverseTransaction, adjustBalance
kycStatus, ssnLast4, routingNumber, accountNumber, governmentIdUrl
quoteExchangeRate, interestAccrued, rewardsPoints, portfolioValue
idempotencyKey, clientMutationId
test cases passed, vs 12 / 25 without
More skills from the same source and nearby in the registry, with their headline benchmark lift.