CVE-2026-50157

Executive Summary

CVE-2026-50157 is an information-disclosure vulnerability in the Auth0 Symfony SDK that affects applications using the Authorizer security authenticator. From version 5.0.0-BETA0 through 5.8.x, protected HTTP routes may accept OAuth 2.0 bearer access tokens supplied via a URL query parameter in addition to the standard Authorization header. Because tokens in URLs are routinely captured in server logs, browser history, and referrer headers, an attacker who obtains such a token can replay it against protected API endpoints. The issue is fixed in version 5.9.0.

Technical Analysis

The vulnerability resides in the token-extraction logic of the Auth0 Symfony SDK's Authorizer security authenticator. Per the vendor description, the affected code paths are Authorizer::authenticate() and Authorizer::supports(). In vulnerable versions (5.0.0-BETA0 through 5.8.x), these methods may accept an OAuth 2.0 bearer access token supplied as a token URL query parameter in addition to the conventional Authorization request header when evaluating access to protected HTTP routes.

This behavior maps to CWE-598 — Use of GET Request Method With Sensitive Query Strings. By permitting bearer tokens to travel in the URL, the SDK creates multiple secondary disclosure channels that do not exist when tokens are confined to headers:

1. Server and proxy logs — Access logs, reverse-proxy logs, and WAF/observability platforms commonly record the full request URI, including query strings. Tokens logged this way are retained in plaintext for the log-retention period.
2. Browser history and client-side storage — Any URL navigated to or fetched by a browser that carries the token is persisted in browser history and may be cached in proxy or intermediate caches.
3. Referrer leakage — If a page whose URL contains the token embeds or navigates to a third-party resource, the full URL (including the query string) may be transmitted in the Referer header to that third party.

The security impact is confidentiality-only: the attacker does not escalate privilege or alter data through the flawed code itself. Instead, the flaw converts a token that should have been a header-only secret into a value that can passively leak through normal infrastructure telemetry. Once an attacker holds the token, the standard bearer-token authorisation flow treats subsequent requests as legitimate — the server cannot distinguish the attacker's replayed request from an authorised one.

Notably, the CVSS vector assigns PR:L (Low privileges), reflecting that a token usable against a protected route represents a low-privileged credential the attacker must first obtain (for example, by reading a log or intercepting a referrer). The vector also assigns C:H (High confidentiality impact) and no integrity or availability impact, consistent with a pure credential-disclosure-and-replay vulnerability.

Exploitation Scenarios

Attack chain inferred from the vulnerability class and NVD description. No public PoC, exploit code, or Nuclei template is available for this CVE.

1. Reconnaissance / target identification. The attacker identifies a Symfony application using the Auth0 Symfony SDK and a reverse proxy or logging stack that records full request URIs. Because vulnerable versions accept the token in a query parameter, legitimate traffic that includes such tokens becomes an observable artifact in logs, caches, or referrer data.

2. Triggering the disclosure path. In the vulnerable configuration, a bearer token is included in the query string of requests to protected routes (for example, by a client integration that follows the SDK's query-parameter path rather than the Authorization header). The vulnerable Authorizer::authenticate() / Authorizer::supports() logic accepts the token from this location. The attacker does not actively exploit a code flaw; the token is exposed passively through the side channels described in Technical Analysis.

3. Token capture. The attacker obtains the token by reading server, proxy, or WAF logs; extracting it from a browser history or shared cache; or intercepting it from a Referer header sent to an attacker-controlled or third-party endpoint. This is the credential-theft step that satisfies the CVSS PR:L precondition.

4. Replay against protected endpoints. With a valid bearer token in hand, the attacker issues requests to the protected API endpoints, presenting the token (the description indicates the vulnerable paths accepted the token via the token query parameter as well as the Authorization header). Since the server-side authorisation logic accepts the token, requests appear as authenticated traffic, allowing the attacker to access resources permitted to the token holder.

No public exploitation has been observed; the chain above follows directly from the described vulnerability behavior and the OAuth 2.0 bearer-token model.

Impact Assessment

The primary impact is confidentiality loss: unauthorised read access to any resource that the leaked bearer token is entitled to reach. High confidentiality impact (C:H) reflects that exposed tokens frequently grant access to user profiles, management APIs, or other protected data. There is no direct integrity or availability impact (I:N / A:N) from the disclosed behavior itself — though an attacker who obtains a sufficiently privileged token (e.g., an Auth0 Management API token) could potentially pivot to data modification, that would be a consequence of the token's scope rather than of this vulnerability.

The blast radius depends on two variables: (1) how widely the vulnerable SDK version is deployed, and (2) which sensitive surfaces retain full URLs — access log aggregators, APM tools, CDN/WAF logs, and shared proxies. Organisations with long log-retention windows and broad log access have the largest exposure. Organisations where tokens are only ever sent in the Authorization header and never in query strings have no exposure through the vulnerable code path, because the flaw is triggered by accepting tokens from the query parameter.

The patch confidence is low (2/4 — CLAIMED): a single source (OSV) indicates a fix in 5.9.0, but this has not been independently confirmed. Affected-system lists and vendor workaround guidance are not available. EPSS is 0.00506 (roughly the 40.9th percentile of exploited CVEs), indicating a low current probability of exploitation in the wild, and the CVE is not in CISA KEV.

Detection Guidance

Sigma Rule

title: Auth0 Symfony SDK Bearer Token Passed via URL Query Parameter
id: 3a9c7f21-5e4b-4c8a-9d10-7b6f2e1c4a55
status: experimental
description: Detects requests to protected routes where an OAuth 2.0 bearer token is supplied in the URL query string rather than the Authorization header, as permitted by vulnerable Auth0 Symfony SDK versions (< 5.9.0).
references:
  - https://nvd.nist.gov/vuln/detail/CVE-2026-50157
  - https://osv.dev/vulnerability/CVE-2026-50157
author: Threat Intelligence
date: 2026/01/01
tags:
  - attack.credential_access
  - attack.t1078
logsource:
  category: webserver
detection:
  selection_auth_header:
    cs-header|contains: 'Authorization'
  selection_query_token:
    cs-uri-query|contains:
      - 'access_token='
      - 'token='
      - 'bearer='
  condition: selection_query_token and not selection_auth_header
falsepositives:
  - Legitimate OAuth2 flows that intentionally use query-string tokens
  - Health checks or monitoring probes containing unrelated 'token' parameters
level: medium

YARA Rule

rule CVE_2026_50157_Auth0_Symfony_Query_Token
{
    meta:
        description = "Detects Auth0 Symfony SDK code references to query-based bearer token acceptance in the Authorizer authenticator"
        author = "Threat Intelligence"
        reference = "https://nvd.nist.gov/vuln/detail/CVE-2026-50157"
        date = "2026-01-01"
        severity = "medium"

    strings:
        $auth0 = "auth0/symfony" ascii nocase
        $class = "Authorizer" ascii
        $m1 = "authenticate" ascii
        $m2 = "supports" ascii
        $q1 = "access_token" ascii nocase
        $q2 = "query" ascii nocase
        $q3 = "getQuery" ascii
        $hdr = "Authorization" ascii

    condition:
        $auth0 or ($class and ($m1 or $m2) and ($q1 or $q2 or $q3))
}

Suricata IDS Rule

alert http any any -> any any (msg:"CVE-2026-50157 Auth0 Symfony SDK Bearer Token in URL Query String"; flow:to_server,established; http.uri; content:"access_token="; nocase; http.uri; content:"token="; nocase; http.header; content:!"Authorization"; nocase; reference:cve,2026-50157; reference:url,nvd.nist.gov/vuln/detail/CVE-2026-50157; classtype:attempted-recon; sid:2026501571; rev:1;)

Elastic Detection

http where http.request.method in ("GET", "POST") and
  stringContains(http.request.uri, "access_token=") and
  not stringContains(http.request.headers, "Authorization")

Splunk SPL Query

index=web sourcetype=access_combined OR sourcetype=proxy
| eval uri_query=lower(uri_query)
| where (like(uri_query, "%access_token=%") OR like(uri_query, "%token=%") OR like(uri_query, "%bearer=%"))
  AND NOT match(_raw, "(?i)authorization")
| stats count values(uri_path) as paths values(clientip) as clients by host
| sort - count

Wazuh OSSEC Rule

<group name="web,auth0,cve_2026_50157,">
  <rule id="2026501" level="8">
    <decoded_as>web-accesslog</decoded_as>
    <field name="url">access_token=</field>
    <description>CVE-2026-50157: OAuth 2.0 bearer token passed in URL query string - possible Auth0 Symfony SDK token disclosure</description>
    <mitre>
      <id>T1078</id>
    </mitre>
    <group>credential_access,</group>
  </rule>
  <rule id="2026502" level="8">
    <decoded_as>web-accesslog</decoded_as>
    <field name="url">token=</field>
    <description>CVE-2026-50157: Possible token in URL query string on protected route (Auth0 Symfony SDK &lt; 5.9.0)</description>
    <mitre>
      <id>T1078</id>
    </mitre>
    <group>credential_access,</group>
  </rule>
</group>

Mitigation & Patch Guidance

Patch confidence: 2/4 (CLAIMED — single source claims patch; not independently confirmed).

1) Immediate mitigations (if unable to upgrade immediately):

• Ensure all clients send OAuth 2.0 bearer tokens exclusively via the Authorization: Bearer <token> header; eliminate any integration that places tokens in query strings.
• Strip token-bearing query parameters at the edge: configure the reverse proxy, API gateway, or WAF to remove or reject access_token, token, and similar parameters before requests reach the application.
• Reduce log exposure: scrub query strings from access logs, APM traces, and WAF records for authentication routes; shorten log-retention windows for authentication traffic and restrict access to those logs.
• Prevent referrer leakage: set Referrer-Policy: no-referrer (or a similarly strict policy) on all pages that could carry tokens in their URL.

2) Patch / upgrade steps:

• Upgrade the Auth0 Symfony SDK to version 5.9.0 or later, which the vendor description states fixes the issue.
• Because the fix is single-sourced (OSV) and unconfirmed, validate post-upgrade that query-string tokens are no longer accepted by Authorizer::authenticate() and Authorizer::supports().
• Rotate any bearer tokens and refresh tokens that may have been exposed in logs, caches, or referrers; invalidate sessions associated with affected tokens.

3) Long-term hardening:

• Enforce a policy that credentials are never placed in URLs; add automated checks (SAST/lint) that fail builds when tokens appear in query strings.
• Adopt short-lived, least-privilege access tokens and rotate them frequently to limit the replay window.
• Centralise and automate dependency monitoring so SDK security advisories are actioned promptly, and maintain an SBOM that flags the Auth0 Symfony SDK across all services.
• Continuously audit log pipelines for sensitive-data capture, applying redaction rules for authentication parameters at ingestion.

References

• NVD — CVE-2026-50157: https://nvd.nist.gov/vuln/detail/CVE-2026-50157
• OSV — CVE-2026-50157 (package record, fix version 5.9.0): https://osv.dev/vulnerability/CVE-2026-50157
• MITRE CWE-598 — Use of GET Request Method With Sensitive Query Strings: https://cwe.mitre.org/data/definitions/598.html
• Auth0 Symfony SDK project: https://github.com/auth0/symfony
• CISA Known Exploited Vulnerabilities Catalog: CVE-2026-50157 is not listed (no exploit-in-the-wild evidence; no public PoC, exploit code, or Nuclei template available).