attack surface

Eight families.
The bug shapes that actually own apps.

Brink doesn't sell coverage of a CVE list. It sells coverage of the bug shapes that actually own apps in 2026 — the ones a scanner finds zero of. This is the catalog, the agent that owns each one, and the funnel every finding has to clear before it reaches you.

attempt → confirm funnel
// how every finding narrows before it reaches you
step 1route hypothesesevery endpoint, param, and flow the agent maps as worth probing
step 2targeted attemptshypotheses the agent actually attacks with a crafted payload
step 3exploit signalattempts that return a response consistent with a real bug
step 4validator passsignals that reproduced clean against a fresh synthetic account
step 5shipped to inboxvalidated findings with a working PoC and a severity
IDOR / BOLAtenant-bleed via path & query params
authz-prober

Authorization checks that miss when the object id is in a header, query string, or a JSON body field the framework auto-parses. The biggest single bucket of real exploits, and the one quarterly pentests miss most often because reproducing one requires two synthetic accounts in the right state.

// sample exploits
  • PATCH /v1/issues/{id} where {id} belongs to another tenant returns 200
  • GET /api/exports/{exportId}.csv with a guessable sequential id
  • cursor-style pagination leaking past the tenant boundary
Auth bypassmissing checks on internal routes, JWT abuse
authn-prober

The endpoint that nobody added a guard to because it was meant to be internal. JWTs with `alg: none`, accepting unsigned tokens, trusting a header that the load balancer was supposed to strip. Severity skews critical — these are the ones that page on-call.

// sample exploits
  • /admin/* with a feature-flag bypass via an X-Forwarded header
  • JWT signature verification skipped when `kid` points to a public URL
  • OAuth callback accepting a `state` from a different session
SSRFwebhook validators, image proxies, oembed
ssrf-prober

Any feature that asks the server to fetch a URL on the user's behalf — webhook test buttons, image proxies, link previews, oembed unfurlers, PDF generators. The agent enumerates them, points them at IMDS, and reads the cloud creds back.

// sample exploits
  • webhook "send test" lands a request at 169.254.169.254 and surfaces the body
  • image proxy that follows redirects to internal IPs and returns the bytes
  • PDF renderer that loads a hostile HTML page with a `file://` link
Race conditionsdouble-spend, coupon stacking, TOCTOU
race-prober

Two requests in the right window beat a check that was meant to fire once. Coupon redemption, refund issuance, balance transfers, account-lock counters. The agent uses single-packet attack techniques to land bursts inside a few milliseconds.

// sample exploits
  • apply the same single-use coupon to 12 carts in parallel
  • two-step withdrawal where the balance check and the deduction are split
  • invite-acceptance flow that races the seat-count guard
Stored XSS chainsuser content → admin viewport → token theft
xss-chainer

XSS on its own is a finding. XSS that lands a payload in the same DOM where an admin reviews user content, and chains to a session-token exfil or a privileged action, is an incident. The agent looks for the chain, not the alert.

// sample exploits
  • comment field renders SVG attributes unescaped in the moderation UI
  • support-ticket viewer that proxies images via a same-origin endpoint
  • admin-only "preview as user" iframe with a permissive postMessage handler
Business logicrefund loops, escalation via API verbs
biz-logic-prober

The bugs scanners can't see because there's no signature — the API does exactly what it says, just in an order or quantity the product team never imagined. Refund the same charge twice. Stack referral bonuses. Escalate via the verb a sibling endpoint forgot to authorize.

// sample exploits
  • partial refunds that sum past the original charge amount
  • PATCH on /memberships/{id} accepts a `role` field that POST validates
  • invitation that survives the org-deletion cascade
Secret exfilAPI keys, MFA seeds, signing material
leak-hunter

Anywhere the app shows the user something it was supposed to keep server-side: HTML comments with debug payloads, API responses that include a `provider_secret` for the wrong tenant, JS bundles with embedded keys from a half-finished feature flag.

// sample exploits
  • tenant settings response includes the Stripe secret key of a paired org
  • public profile JSON includes `mfa_recovery_codes` for the viewer
  • a feature-flagged debug endpoint that returns env vars when reached over websocket
Token & sessionJWT replay, refresh-token reuse, idle bypass
session-prober

The session model has rules — short-lived access token, single-use refresh, idle timeout, IP binding. Each rule is enforced somewhere. The agent looks for the requests that escape one of them and chains the others.

// sample exploits
  • refresh token reusable for 30s after rotation (race window)
  • session "active" check that ignores explicit logout for SSO sessions
  • access token from staging accepted in prod because the JWKS URL is shared
a note on the bar

Everything we ship is "validator-confirmed" — the finding reproduces against a real synthetic account, the PoC runs clean a second time, and a human-readable severity is assigned. We don't surface "potential" or "low-confidence" findings because we don't ship them to your inbox either. Once we're running against live targets we intend to publish transparency reports — false-positive rate by family, MTTR for fix PRs — at /blog.

the obvious follow-up
Want one of these ran against your staging? First confirmed exploit in 24 hours or you owe us nothing.