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

---

### SSH certificate-authority trust forgery (Git-hosting / enterprise platforms) When an org or instance registers an SSH certificate authority, cert `principals` may not be bound server-side to the requesting identity — a member can mint a cert asserting another user's principal and authenticate as them (e.g. modify another user's resource given only its URL). Add SSH-CA trust to the auth-surface list on Git-hosting targets; niche/platform-specific. Disclosed: reports/1901040.

## 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:** ```javascript // 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 | |---|---|---| | **WordPress** | `/xmlrpc.php` (`system.listMethods`, `wp.getUsersBlogs`, `system.multicall`) | Native WP user/pass; bypasses SSO, MFA, IP-allow rules on `/wp-login.php` | | **WordPress (REST)** | `/?rest_route=/wp/v2/users`, `/wp-json/wp/v2/users` | User enumeration anonymously even when login page is hardened | | **SharePoint (any version)** | `/_vti_bin/Authentication.asmx` (`Mode` + `Login` SOAP ops) | Native Forms-auth credential; FedAuth cookie returned; no rate limit on this endpoint observed on SP2013 farms — **this is the canonical SP equivalent of the WP XMLRPC bypass** | | **SharePoint legacy** | `/_vti_bin/_vti_aut/author.dll`, `/_vti_bin/_vti_adm/admin.dll`, `/_vti_bin/owssvr.dll` | FrontPage RPC; sometimes still wired to credential validators | | **SharePoint REST** | `/_api/contextinfo` (POST), `/_api/$metadata` | Anonymous FormDigest issuance; full API surface enumeration | | **Atlassian (Jira / Confluence)** | `/rest/auth/1/session` (basic-auth), `/rest/api/2/myself`, legacy `/rest/api/1.0/` | Native credentials accepted on `/rest/auth/1/session` even when Atlassian Crowd / Atlassian Access SSO is enforced on the UI | | **Drupal** | `/jsonapi/`, `/user/login?_format=json` | JSON POST endpoint that accepts native passwords; separate from SSO middleware | | **Drupal (D7 legacy)** | `/?q=user/login`, `/services/`, `/rest/` | Older REST modules with independent auth | | **Joomla** | `/administrator/index.php?option=com_login`, `/api/index.php/v1/users` | Native Joomla credentials accepted on admin entry independent of any front-site SSO | | **Exchange / OWA** | `/EWS/Exchange.asmx`, `/Autodiscover/Autodiscover.xml`, `/Microsoft-Server-ActiveSync` | NTLM / Basic; bypasses OWA UI restrictions (MFA, IP-allow). The classic CVE-2020-0688 / CVE-2021-26855 surface | | **Citrix NetScaler** | `/vpn/index.html`, `/cgi/login`, `/nf/auth/doAuthentication.do` | Native AD credentials; independent of MFA wrappers | | **F5 BIG-IP** | `/mgmt/tm/util/bash`, `/tmui/login.jsp` | Native admin credentials | | **Generic ASP.NET app** | `*.asmx?WSDL`, `*.svc?WSDL`, `trace.axd`, `elmah.axd`, `.disco` | Find every web service; many take credentials independently of the WebForms login | | **Spring Boot** | `/actuator/*`, `/management/*`, `/api/v1/auth/login`, `/api/v1/swagger-ui` | Actuator endpoints sometimes anonymously enumerable | | **Jenkins** | `/jnlpJars/jenkins-cli.jar`, `/script`, `/manage`, `/computer/(master)/script` | API tokens + native auth | | **GitLab** | `/api/v3/*` (deprecated but still on old installs), `/api/v4/users`, `/api/v4/projects` | Personal Access Tokens with looser scoping than UI session | | **TeamCity** | `/app/rest/users`, `/login.html?username=&password=` (GET-form-login) | Native admin credentials | | **Apache Tomcat** | `/manager/html`, `/host-manager/html`, `/manager/text/list` | Native Tomcat realm credentials independent of any front auth | | **WebLogic** | `/console/login/LoginForm.jsp`, `/wls-wsat/*` | Native admin | | **Oracle EBS / PeopleSoft** | `/OA_HTML/AppsLogin`, `/psp/*/?cmd=login` | Native ERP credentials |

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

**Lesson from a authorized engagement:** A an enterprise dealer portal on SharePoint 2013 had a custom branded `customlogin.aspx`. The hunt-auth-bypass skill was loaded but the matrix above did not exist in this document — and the WordPress XMLRPC pattern was not connected to the SharePoint equivalent. `/_vti_bin/Authentication.asmx` was reachable anonymously, accepted unlimited credential attempts with no rate limit and no lockout, and was the highest-impact finding in the engagement. Walking this matrix on the first pass would have surfaced it immediately.

---

## Payload & Detection Patterns

**XMLRPC auth probe (bypasses SSO):** ```bash 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):** ```python 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):** ```xml <!-- Original NameID --> <NameID>attacker@evil.com</NameID>

<!-- Injected

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

---

### SSH certificate-authority trust forgery (Git-hosting / enterprise platforms) When an org or instance registers an SSH certificate authority, cert `principals` may not be bound server-side to the requesting identity — a member can mint a cert asserting another user's principal and authenticate as them (e.g. modify another user's resource given only its URL). Add SSH-CA trust to the auth-surface list on Git-hosting targets; niche/platform-specific. Disclosed: reports/1901040.

## 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:** ```javascript // 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 | |---|---|---| | **WordPress** | `/xmlrpc.php` (`system.listMethods`, `wp.getUsersBlogs`, `system.multicall`) | Native WP user/pass; bypasses SSO, MFA, IP-allow rules on `/wp-login.php` | | **WordPress (REST)** | `/?rest_route=/wp/v2/users`, `/wp-json/wp/v2/users` | User enumeration anonymously even when login page is hardened | | **SharePoint (any version)** | `/_vti_bin/Authentication.asmx` (`Mode` + `Login` SOAP ops) | Native Forms-auth credential; FedAuth cookie returned; no rate limit on this endpoint observed on SP2013 farms — **this is the canonical SP equivalent of the WP XMLRPC bypass** | | **SharePoint legacy** | `/_vti_bin/_vti_aut/author.dll`, `/_vti_bin/_vti_adm/admin.dll`, `/_vti_bin/owssvr.dll` | FrontPage RPC; sometimes still wired to credential validators | | **SharePoint REST** | `/_api/contextinfo` (POST), `/_api/$metadata` | Anonymous FormDigest issuance; full API surface enumeration | | **Atlassian (Jira / Confluence)** | `/rest/auth/1/session` (basic-auth), `/rest/api/2/myself`, legacy `/rest/api/1.0/` | Native credentials accepted on `/rest/auth/1/session` even when Atlassian Crowd / Atlassian Access SSO is enforced on the UI | | **Drupal** | `/jsonapi/`, `/user/login?_format=json` | JSON POST endpoint that accepts native passwords; separate from SSO middleware | | **Drupal (D7 legacy)** | `/?q=user/login`, `/services/`, `/rest/` | Older REST modules with independent auth | | **Joomla** | `/administrator/index.php?option=com_login`, `/api/index.php/v1/users` | Native Joomla credentials accepted on admin entry independent of any front-site SSO | | **Exchange / OWA** | `/EWS/Exchange.asmx`, `/Autodiscover/Autodiscover.xml`, `/Microsoft-Server-ActiveSync` | NTLM / Basic; bypasses OWA UI restrictions (MFA, IP-allow). The classic CVE-2020-0688 / CVE-2021-26855 surface | | **Citrix NetScaler** | `/vpn/index.html`, `/cgi/login`, `/nf/auth/doAuthentication.do` | Native AD credentials; independent of MFA wrappers | | **F5 BIG-IP** | `/mgmt/tm/util/bash`, `/tmui/login.jsp` | Native admin credentials | | **Generic ASP.NET app** | `*.asmx?WSDL`, `*.svc?WSDL`, `trace.axd`, `elmah.axd`, `.disco` | Find every web service; many take credentials independently of the WebForms login | | **Spring Boot** | `/actuator/*`, `/management/*`, `/api/v1/auth/login`, `/api/v1/swagger-ui` | Actuator endpoints sometimes anonymously enumerable | | **Jenkins** | `/jnlpJars/jenkins-cli.jar`, `/script`, `/manage`, `/computer/(master)/script` | API tokens + native auth | | **GitLab** | `/api/v3/*` (deprecated but still on old installs), `/api/v4/users`, `/api/v4/projects` | Personal Access Tokens with looser scoping than UI session | | **TeamCity** | `/app/rest/users`, `/login.html?username=&password=` (GET-form-login) | Native admin credentials | | **Apache Tomcat** | `/manager/html`, `/host-manager/html`, `/manager/text/list` | Native Tomcat realm credentials independent of any front auth | | **WebLogic** | `/console/login/LoginForm.jsp`, `/wls-wsat/*` | Native admin | | **Oracle EBS / PeopleSoft** | `/OA_HTML/AppsLogin`, `/psp/*/?cmd=login` | Native ERP credentials |

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

**Lesson from a authorized engagement:** A an enterprise dealer portal on SharePoint 2013 had a custom branded `customlogin.aspx`. The hunt-auth-bypass skill was loaded but the matrix above did not exist in this document — and the WordPress XMLRPC pattern was not connected to the SharePoint equivalent. `/_vti_bin/Authentication.asmx` was reachable anonymously, accepted unlimited credential attempts with no rate limit and no lockout, and was the highest-impact finding in the engagement. Walking this matrix on the first pass would have surfaced it immediately.

---

## Payload & Detection Patterns

**XMLRPC auth probe (bypasses SSO):** ```bash 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):** ```python 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):** ```xml <!-- Original NameID --> <NameID>attacker@evil.com</NameID>

<!-- Injected

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

---

### SSH certificate-authority trust forgery (Git-hosting / enterprise platforms) When an org or instance registers an SSH certificate authority, cert `principals` may not be bound server-side to the requesting identity — a member can mint a cert asserting another user's principal and authenticate as them (e.g. modify another user's resource given only its URL). Add SSH-CA trust to the auth-surface list on Git-hosting targets; niche/platform-specific. Disclosed: reports/1901040.

## 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:** ```javascript // 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 | |---|---|---| | **WordPress** | `/xmlrpc.php` (`system.listMethods`, `wp.getUsersBlogs`, `system.multicall`) | Native WP user/pass; bypasses SSO, MFA, IP-allow rules on `/wp-login.php` | | **WordPress (REST)** | `/?rest_route=/wp/v2/users`, `/wp-json/wp/v2/users` | User enumeration anonymously even when login page is hardened | | **SharePoint (any version)** | `/_vti_bin/Authentication.asmx` (`Mode` + `Login` SOAP ops) | Native Forms-auth credential; FedAuth cookie returned; no rate limit on this endpoint observed on SP2013 farms — **this is the canonical SP equivalent of the WP XMLRPC bypass** | | **SharePoint legacy** | `/_vti_bin/_vti_aut/author.dll`, `/_vti_bin/_vti_adm/admin.dll`, `/_vti_bin/owssvr.dll` | FrontPage RPC; sometimes still wired to credential validators | | **SharePoint REST** | `/_api/contextinfo` (POST), `/_api/$metadata` | Anonymous FormDigest issuance; full API surface enumeration | | **Atlassian (Jira / Confluence)** | `/rest/auth/1/session` (basic-auth), `/rest/api/2/myself`, legacy `/rest/api/1.0/` | Native credentials accepted on `/rest/auth/1/session` even when Atlassian Crowd / Atlassian Access SSO is enforced on the UI | | **Drupal** | `/jsonapi/`, `/user/login?_format=json` | JSON POST endpoint that accepts native passwords; separate from SSO middleware | | **Drupal (D7 legacy)** | `/?q=user/login`, `/services/`, `/rest/` | Older REST modules with independent auth | | **Joomla** | `/administrator/index.php?option=com_login`, `/api/index.php/v1/users` | Native Joomla credentials accepted on admin entry independent of any front-site SSO | | **Exchange / OWA** | `/EWS/Exchange.asmx`, `/Autodiscover/Autodiscover.xml`, `/Microsoft-Server-ActiveSync` | NTLM / Basic; bypasses OWA UI restrictions (MFA, IP-allow). The classic CVE-2020-0688 / CVE-2021-26855 surface | | **Citrix NetScaler** | `/vpn/index.html`, `/cgi/login`, `/nf/auth/doAuthentication.do` | Native AD credentials; independent of MFA wrappers | | **F5 BIG-IP** | `/mgmt/tm/util/bash`, `/tmui/login.jsp` | Native admin credentials | | **Generic ASP.NET app** | `*.asmx?WSDL`, `*.svc?WSDL`, `trace.axd`, `elmah.axd`, `.disco` | Find every web service; many take credentials independently of the WebForms login | | **Spring Boot** | `/actuator/*`, `/management/*`, `/api/v1/auth/login`, `/api/v1/swagger-ui` | Actuator endpoints sometimes anonymously enumerable | | **Jenkins** | `/jnlpJars/jenkins-cli.jar`, `/script`, `/manage`, `/computer/(master)/script` | API tokens + native auth | | **GitLab** | `/api/v3/*` (deprecated but still on old installs), `/api/v4/users`, `/api/v4/projects` | Personal Access Tokens with looser scoping than UI session | | **TeamCity** | `/app/rest/users`, `/login.html?username=&password=` (GET-form-login) | Native admin credentials | | **Apache Tomcat** | `/manager/html`, `/host-manager/html`, `/manager/text/list` | Native Tomcat realm credentials independent of any front auth | | **WebLogic** | `/console/login/LoginForm.jsp`, `/wls-wsat/*` | Native admin | | **Oracle EBS / PeopleSoft** | `/OA_HTML/AppsLogin`, `/psp/*/?cmd=login` | Native ERP credentials |

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

**Lesson from a authorized engagement:** A an enterprise dealer portal on SharePoint 2013 had a custom branded `customlogin.aspx`. The hunt-auth-bypass skill was loaded but the matrix above did not exist in this document — and the WordPress XMLRPC pattern was not connected to the SharePoint equivalent. `/_vti_bin/Authentication.asmx` was reachable anonymously, accepted unlimited credential attempts with no rate limit and no lockout, and was the highest-impact finding in the engagement. Walking this matrix on the first pass would have surfaced it immediately.

---

## Payload & Detection Patterns

**XMLRPC auth probe (bypasses SSO):** ```bash 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):** ```python 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):** ```xml <!-- Original NameID --> <NameID>attacker@evil.com</NameID>

<!-- Injected

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

---

### SSH certificate-authority trust forgery (Git-hosting / enterprise platforms) When an org or instance registers an SSH certificate authority, cert `principals` may not be bound server-side to the requesting identity — a member can mint a cert asserting another user's principal and authenticate as them (e.g. modify another user's resource given only its URL). Add SSH-CA trust to the auth-surface list on Git-hosting targets; niche/platform-specific. Disclosed: reports/1901040.

## 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:** ```javascript // 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 | |---|---|---| | **WordPress** | `/xmlrpc.php` (`system.listMethods`, `wp.getUsersBlogs`, `system.multicall`) | Native WP user/pass; bypasses SSO, MFA, IP-allow rules on `/wp-login.php` | | **WordPress (REST)** | `/?rest_route=/wp/v2/users`, `/wp-json/wp/v2/users` | User enumeration anonymously even when login page is hardened | | **SharePoint (any version)** | `/_vti_bin/Authentication.asmx` (`Mode` + `Login` SOAP ops) | Native Forms-auth credential; FedAuth cookie returned; no rate limit on this endpoint observed on SP2013 farms — **this is the canonical SP equivalent of the WP XMLRPC bypass** | | **SharePoint legacy** | `/_vti_bin/_vti_aut/author.dll`, `/_vti_bin/_vti_adm/admin.dll`, `/_vti_bin/owssvr.dll` | FrontPage RPC; sometimes still wired to credential validators | | **SharePoint REST** | `/_api/contextinfo` (POST), `/_api/$metadata` | Anonymous FormDigest issuance; full API surface enumeration | | **Atlassian (Jira / Confluence)** | `/rest/auth/1/session` (basic-auth), `/rest/api/2/myself`, legacy `/rest/api/1.0/` | Native credentials accepted on `/rest/auth/1/session` even when Atlassian Crowd / Atlassian Access SSO is enforced on the UI | | **Drupal** | `/jsonapi/`, `/user/login?_format=json` | JSON POST endpoint that accepts native passwords; separate from SSO middleware | | **Drupal (D7 legacy)** | `/?q=user/login`, `/services/`, `/rest/` | Older REST modules with independent auth | | **Joomla** | `/administrator/index.php?option=com_login`, `/api/index.php/v1/users` | Native Joomla credentials accepted on admin entry independent of any front-site SSO | | **Exchange / OWA** | `/EWS/Exchange.asmx`, `/Autodiscover/Autodiscover.xml`, `/Microsoft-Server-ActiveSync` | NTLM / Basic; bypasses OWA UI restrictions (MFA, IP-allow). The classic CVE-2020-0688 / CVE-2021-26855 surface | | **Citrix NetScaler** | `/vpn/index.html`, `/cgi/login`, `/nf/auth/doAuthentication.do` | Native AD credentials; independent of MFA wrappers | | **F5 BIG-IP** | `/mgmt/tm/util/bash`, `/tmui/login.jsp` | Native admin credentials | | **Generic ASP.NET app** | `*.asmx?WSDL`, `*.svc?WSDL`, `trace.axd`, `elmah.axd`, `.disco` | Find every web service; many take credentials independently of the WebForms login | | **Spring Boot** | `/actuator/*`, `/management/*`, `/api/v1/auth/login`, `/api/v1/swagger-ui` | Actuator endpoints sometimes anonymously enumerable | | **Jenkins** | `/jnlpJars/jenkins-cli.jar`, `/script`, `/manage`, `/computer/(master)/script` | API tokens + native auth | | **GitLab** | `/api/v3/*` (deprecated but still on old installs), `/api/v4/users`, `/api/v4/projects` | Personal Access Tokens with looser scoping than UI session | | **TeamCity** | `/app/rest/users`, `/login.html?username=&password=` (GET-form-login) | Native admin credentials | | **Apache Tomcat** | `/manager/html`, `/host-manager/html`, `/manager/text/list` | Native Tomcat realm credentials independent of any front auth | | **WebLogic** | `/console/login/LoginForm.jsp`, `/wls-wsat/*` | Native admin | | **Oracle EBS / PeopleSoft** | `/OA_HTML/AppsLogin`, `/psp/*/?cmd=login` | Native ERP credentials |

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

**Lesson from a authorized engagement:** A an enterprise dealer portal on SharePoint 2013 had a custom branded `customlogin.aspx`. The hunt-auth-bypass skill was loaded but the matrix above did not exist in this document — and the WordPress XMLRPC pattern was not connected to the SharePoint equivalent. `/_vti_bin/Authentication.asmx` was reachable anonymously, accepted unlimited credential attempts with no rate limit and no lockout, and was the highest-impact finding in the engagement. Walking this matrix on the first pass would have surfaced it immediately.

---

## Payload & Detection Patterns

**XMLRPC auth probe (bypasses SSO):** ```bash 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):** ```python 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):** ```xml <!-- Original NameID --> <NameID>attacker@evil.com</NameID>

<!-- Injected