hunt-fintech-graphql

> **⚠️ AUTHORIZED USE ONLY**

> This skill is for educational purposes or authorized security assessments only.

> You must have explicit, written permission from the system owner before using this tool.

> Misuse of this tool is illegal and strictly prohibited.

> **Mandatory confirmation gate**

> Before running any command that probes, exploits, changes, persists on, extracts data from, or attempts credential access against a target:

> 1. Ask the user to state the exact target URL, IP, account, or resource.

> 2. Ask the user to confirm written authorization and the permitted scope.

> 3. Show the exact command(s) and explain their expected effect.

> 4. Wait for explicit confirmation in the current conversation.

>

> Without that confirmation, remain read-only and provide defensive guidance only. Prefer a sandbox, disposable VM, or controlled lab.

Why Fintech GraphQL Is a Different Risk Class

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:

- **Money-movement mutations are almost always resolvers over a double-entry ledger.** A single

GraphQL mutation (`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.

- **Decimals are attacker-controlled input, not display formatting.** Amounts, exchange rates,

interest, and rewards points are usually passed as GraphQL scalars (`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.

- **KYC/PII fields sit next to routine account fields in the same type.** `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.

---

Attack Surface Signals

**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

**Tech-stack tells specific to this vertical:**

- Plaid/Stripe/Dwolla/Marqeta wrapped behind an internal GraphQL gateway (`bankLink`, `plaidLinkToken` mutations)

- Apollo Federation with a dedicated `ledger` or `payments` subgraph — check for the subgraph's own introspection being reachable directly, bypassing the gateway's stitched-down schema

- Custom `Money`/`Decimal`/`BigDecimal` GraphQL scalar in the schema (`scalar Money`) — the parser for this scalar is worth fuzzing directly

Run `hunt-graphql`'s discovery + introspection methodology first to get the schema; everything

below assumes you already have (or have partially enumerated) a schema with money-movement types.

---

Step-by-Step Hunting Methodology

1. **Map every mutation that touches balance, whether directly or as a side effect.** Not just

`transfer*`/`withdraw*` — also `redeemRewards`, `applyCoupon`, `upgradeTier`,

`closeAccount` (often refunds a balance), `disputeTransaction` (often provisionally credits).

2. **For each money-movement mutation, identify the ledger wri