Hunt Auth Bypass

Gate 0 Validation

Before writing any report, answer these three questions:

1. What can the attacker DO right now? Must be: authenticate as another user OR authenticate without valid credentials OR elevate to admin/privileged role. "Partial information disclosure" is not auth bypass.

2. What does the victim LOSE? Must identify a concrete asset: account takeover of specific user, access to all admin functions, ability to read/modify other tenants' data, or access to privileged APIs. Abstract "security control bypass" without impact is not sufficient.

3. Can it be reproduced in 10 minutes from scratch? You must be able to: (a) start from a fresh browser/session, (b) follow your exact steps, and (c) arrive at authenticated access to a protected resource. If reproduction requires special preconditions you can't re-create (a specific victim's active session, timing windows), the report needs more work.

Real Impact Examples

Scenario 1 — SSO Enforcement Bypassed via Forgotten Protocol Endpoint A large ride-sharing company enforced SSO (via OneLogin) on all WordPress-based internal/public properties. The XMLRPC endpoint (/xmlrpc.php) remained active and accepted WordPress-native credentials entirely independent of the SSO flow. An attacker with any valid WP-native credentials (obtained via credential stuffing or from a previous breach) could authenticate directly through XMLRPC, bypassing MFA, SSO policies, and IP restrictions enforced on the main login form. Impact: Full authenticated access to all WordPress functions available to that user role, including content management and potentially admin functions.

Scenario 2 — SAML Assertion Forgery via Signature Validation Failure A major enterprise communication platform's SAML SP implementation failed to properly validate assertion signatures in specific edge cases. By manipulating the XML structure of a captured SAMLResponse (specifically through comment injection or namespace prefix attacks), an attacker could modify the NameID value to impersonate any user in an organization — including workspace administrators — without possessing that user's credentials or private key material. Impact: Complete account takeover of any user within a SAML-enabled organization; attacker gains access to all messages, files, and integrations in the workspace.

Scenario 3 — Cross-Portal Privilege Escalation via Shared Auth Backend An e-commerce platform's partner/reseller portal issued authentication tokens that were validated by the same backend service as the merchant admin portal. A partner-level account (lower trust, external-facing) could use its issued credentials or tokens to authenticate directly against admin-tier API endpoints, bypassing the merchant onboarding and permission assignment flow. Impact: A malicious partner could access any merchant's admin panel, modify store configurations, exfiltrate customer PII and payment data, or install malicious scripts — affecting thousands of merchant storefronts.

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

Contents

• Duende BFF — Token-Confusion & Session-Fixation (2024-2026 surface)
• Function-Level Access Control (Broken Authorization)
• Related Skills & Chains

When to Use

• You have explicit, written authorization to assess the target in scope, and the task matches this skill's vulnerability class or technique within a bug-bounty or penetration-test engagement.
• You need the recon, exploitation, or validation workflow described below — executed strictly inside the approved scope.

Limitations

• Authorized scope only: the confirmation gate above is mandatory before any probing, exploitation, or credential-access command.
• Docs-only import: upstream helper scripts, commands, engine, and research assets are not bundled; reinstall tooling from the source repo when needed.
• Validate every finding (see triage-validation) before reporting; report via report-writing. Prefer a sandbox, disposable VM, or controlled lab.

Example

# Read-only first step; confirm scope before anything active.
cat scope.txt  # target list from the authorized engagement brief

Adapted from elementalsouls/Claude-BugHunter (MIT); frontmatter, When to Use/Limitations, and safety boundaries added for upstream compliance. Docs-only import: executable helpers, commands, engine, and research assets not bundled.