/hunt-auth-bypass

name: hunt-auth-bypass
description: Hunting skill for auth bypass vulnerabilities. Built from 12 public bug bounty reports across SAML XSW / parser-differential (GitHub Enterprise CVE-2025-25291/25292), SAML signature stripping (Uber, Rocket.Chat, samlify CVE-2025-47949), SAML domain enforcement bypass via control characters (HackerOne 2024), partner-portal cross-IdP assertion reuse (Slack), WordPress XMLRPC bypassing SSO (Uber), JWT alg-confusion HS256/RS256 (Jitsi), JWT signature-validation skip (Linktree, Newspack), and token-audience confusion (Argo CD CVE-2023-22482). For standalone JWT signature/crypto forging (alg:none, key confusion, kid/jku) see hunt-jwt-crypto; this skill covers JWT only inside SSO/SAML/token-trust bypass chains. SAML assertion-layer attacks (XSW, comment injection, signature stripping, XXE-in-assertion) are owned by hunt-saml; this skill owns the broader cross-protocol auth-bypass taxonomy. Use when hunting auth bypass — see the Legacy-Protocol Matrix for branded-UI vs legacy-endpoint patterns.
sources: github, hackerone_public, github_security_lab, projectdiscovery_research
report_count: 12

Crown Jewel Targets

Auth bypass is consistently one of the highest-paying vulnerability classes in bug bounty because it directly violates the most fundamental security control. High-value targets include:

• **SSO/SAML implementations** at enterprise SaaS companies (Slack, Okta, OneLogin integrations) — payouts regularly in the $5K–$25K+ range
• **Admin panels and partner/internal portals** — subdomain-separated admin surfaces like `partners.shopify.com`, `admin.company.com`
• **Third-party auth plugin integrations** — WordPress plugins (OneLogin, WP-SAML-Auth), Drupal SSO modules, any CMS with pluggable auth
• **XMLRPC endpoints** on WordPress — often forgotten, bypasses standard WP auth flows entirely
• **OAuth callback flows** — state parameter mishandling, redirect_uri mismatches
• **API authentication layers** — especially where auth was bolted on after the fact

**Asset priority:** Targets with federated identity (SAML, OAuth, OIDC) connected to large user populations. Partner/reseller portals are particularly juicy because they often have elevated permissions and less security scrutiny than the main product.

---

Attack Surface Signals

**URL patterns to hunt:**

/xmlrpc.php
/wp-login.php
/saml/
/sso/
/auth/saml/callback
/oauth/callback
/partners.*
/admin.*
/?wc-api=
/api/v*/auth
/login?redirect=
/accounts/login

**Response headers signaling SSO:**

X-Frame-Options: SAMEORIGIN (common on SSO portals)
Set-Cookie: SAMLResponse=
Location: https://idp.company.com/saml
WWW-Authenticate: Bearer realm="partners"

**JS patterns indicating federated auth:**

// Look for in page source
samlRequest
RelayState
SAMLResponse
onelogin
shibboleth
okta
passport.js authenticate

**Tech stack signals:**

• WordPress + any SSO plugin → check XMLRPC separately
• Shopify Partner API exposure → cross-tenant privilege escalation risk
• Any app advertising "SSO enabled" or "Login with [Enterprise IdP]"
• Separate subdomains for admin/partner that share session cookies with main domain
• Applications using `SimpleSAMLphp`, `ruby-saml`, `python-saml`

**Burp passive scan triggers:**

• `SAMLResponse` in any POST body
• `openid_connect` or `id_token` in responses
• Cookie domains set to `.company.com` (wildcard)

---

Step-by-Step Hunting Methodology

1. **Map all authentication entry points**

• spider the target for every login surface: main login, admin login, API login, partner portal, mobile API endpoints
• check `robots.txt`, JS files, and the wayback machine for forgotten endpoints like `/xmlrpc.php`

2. **Identify the auth mechanism per entry point**

• Is it forms-based, SAML, OAuth, API key, session token?
• For WordPress: always probe `/xmlrpc.php` even if the main login is SSO-protected

3. **Test XMLRPC independently of SSO**

• If site uses SSO (e.g., OneLogin), manually POST to `/xmlrpc.php`
• XMLRPC uses WordPress-native credentials, not SSO — test with `system.listMethods` first, then `wp.getUsersBlogs`

4. **Enumerate SAML implementation**

• Capture a valid SAMLResponse via Burp
• Decode the Base64 payload, inspect the XML
• Test signature stripping, comment injection, and XML wrapping attacks
• Test if SP validates the signature at all (send unsigned assertion)

5. **Test cross-portal session/token reuse**

• Log into `partners.shopify.com` type portals
• Attempt to use the issued token/cookie against the main admin portal
• Look for shared cookie domains, shared JWT secrets, or API tokens that work across contexts

6. **Fuzz auth parameters**

• Null/empty passwords, `password[]=array`, SQL in username field
• Try `admin`/`admin`, `test`/`test` on staging subdomains
• Modify `role`, `is_admin`, `user_type` in JWTs (none algorithm, weak secret)

7. **Check redirect and state parameters**

• Does removing `state` from OAuth break anything?
• Can you change `redirect_uri` to an open redirect target?
• Does the `RelayState` in SAML get validated?

8. **Verify impact by escalating privileges**

• Don't stop at login — prove you can access admin functions, other users' data, or sensitive configuration
• Screenshot the highest-privilege action you can perform

---

Legacy-Protocol Matrix (Probe These First on Any Custom-Branded Login)

When a target has a custom, branded login UI (e.g. `customlogin.aspx`, `/auth/signin`, `/account/login`), **always probe the platform's legacy protocol endpoints with native credentials** in parallel. These endpoints frequently outlive the custom UI's protections and accept native credentials with NO rate limit, NO MFA challenge, NO CAPTCHA, NO anti-automation. This is the WordPress XMLRPC pattern generalised across CMS / portal / framework stacks.

| Target tech | Legacy endpoint(s) to probe | Native-cred bypass surface | |---|---|---| | **W