CVE-2026-50157: Auth0 Symfony Auth Bypass Vulnerability

CVE-2026-50157 Overview

CVE-2026-50157 affects the Auth0 Symfony SDK, a library that integrates Symfony applications with Auth0 Authentication and Management APIs. Versions from 5.0.0-BETA0 through 5.8.x accept OAuth 2.0 bearer access tokens supplied through the URL query string in addition to the standard Authorization header. The Authorizer::authenticate() and Authorizer::supports() methods in the security authenticator treat query-string tokens as valid credentials on protected HTTP routes. Query-string tokens are routinely captured by web server access logs, browser history, and HTTP Referer headers. An attacker who obtains a leaked token can replay it against protected API endpoints. The issue is tracked under [CWE-598: Use of GET Request Method With Sensitive Query Strings] and is resolved in version 5.9.0.

Critical Impact

Bearer tokens exposed in server logs, browser history, or referrer data can be replayed by attackers to authenticate against protected Auth0-secured API endpoints, leading to unauthorized access to user resources.

Affected Products

• Auth0 Symfony SDK versions 5.0.0-BETA0 through 5.8.x
• Symfony applications using the Authorizer security authenticator from the auth0/symfony package
• API routes protected by the Auth0 bearer token authentication flow

Discovery Timeline

• 2026-09-14 - CVE-2026-50157 published to NVD
• 2026-09-14 - Last updated in NVD database
• 2026-09-14 - GitHub Security Advisory GHSA-ffq7-hh2j-r24p published

Technical Details for CVE-2026-50157

Vulnerability Analysis

The Auth0 Symfony SDK provides an Authorizer class that implements Symfony's AbstractAuthenticator interface. This authenticator is invoked on protected routes to extract and validate OAuth 2.0 bearer tokens from inbound requests. In affected versions, the supports() method returns true when a token appears in the token query-string parameter, and authenticate() accepts that value as a valid credential. This behavior conflicts with RFC 6750 Section 2.3, which discourages URI query parameters for bearer credentials due to leakage risks.

An authenticated attacker who obtains a token from any secondary source — such as a shared web server access log, a proxy log, or a browser history export — can replay that token in the Authorization header against protected endpoints. No decryption, forging, or session hijacking is required.

Root Cause

The root cause is over-permissive credential extraction in the Authorizer security authenticator. The src/Security/Authorizer.php class accepted bearer tokens from two transport locations rather than restricting acceptance to the Authorization: Bearer header. This design allowed tokens to traverse channels that persist request URIs, including HTTP intermediaries, browser history, and Referer headers sent to third-party origins.

Attack Vector

Exploitation is network-based and requires the attacker to acquire a valid token that was previously transmitted via a query string. Common acquisition paths include reading web server access logs, retrieving cached browser history from a compromised workstation, or receiving the token in a Referer header when the application links out to an external site. The attacker then replays the captured token against any protected route that uses the Authorizer.

 use Symfony\Component\Security\Http\Authenticator\Passport\Badge\UserBadge;
 use Symfony\Component\Security\Http\Authenticator\Passport\{Passport, SelfValidatingPassport};
 
-use function is_string;
-
 final class Authorizer extends AbstractAuthenticator implements AuthorizerInterface
 {
     /**

Source: GitHub commit bd1851b. The patch removes the query-string token acceptance path from the Authorizer class, forcing bearer credentials to be presented only via the Authorization header.

Detection Methods for CVE-2026-50157

Indicators of Compromise

• Web server access logs containing requests with a token= query-string parameter on routes secured by the Auth0 Authorizer
• Repeated successful authentications for the same access token from multiple client IP addresses or user agents
• Requests to protected API endpoints where the Referer header of downstream traffic contains an access token value
• Presence of auth0/symfony package versions between 5.0.0-BETA0 and 5.8.x in composer.lock

Detection Strategies

• Grep archived web server, load balancer, and reverse proxy logs for URI patterns containing token= on routes handled by the Auth0 authenticator.
• Correlate access-token usage across source IPs to identify tokens presented from geographies or networks that do not match the token subject's normal behavior.
• Run static dependency analysis (composer show auth0/symfony) across build artifacts to surface vulnerable SDK versions in production and staging environments.

Monitoring Recommendations

• Alert when Symfony application logs record authentication events sourced from query-string credentials rather than the Authorization header.
• Monitor egress traffic for outbound Referer headers containing the string token= on domains that host the Symfony application.
• Track token issuance-to-first-use latency and geographic anomalies through the Auth0 dashboard to catch replayed credentials.

How to Mitigate CVE-2026-50157

Immediate Actions Required

• Upgrade the auth0/symfony package to version 5.9.0 or later using composer require auth0/symfony:^5.9.0.
• Rotate any OAuth 2.0 access tokens and refresh tokens that may have been transmitted through query-string parameters while the vulnerable SDK was in use.
• Purge or restrict access to historical web server, proxy, and CDN logs that captured requests with token= URI parameters.

Patch Information

The fix is delivered in Auth0 Symfony SDK release 5.9.0 via commit bd1851b. The patch removes the code path in src/Security/Authorizer.php that extracts bearer tokens from the query string, aligning the authenticator with RFC 6750 guidance. Refer to GHSA-ffq7-hh2j-r24p for the full advisory.

Workarounds

• If upgrading immediately is not feasible, place a reverse proxy or WAF rule in front of the application that strips the token query parameter before requests reach the Symfony Authorizer.
• Configure clients and integrations to send bearer credentials only in the Authorization: Bearer <token> header and reject query-string authentication at the application gateway.
• Shorten access token lifetimes in the Auth0 tenant configuration to reduce the replay window for any tokens that may have leaked into logs or browser history.

# Upgrade the Auth0 Symfony SDK to the patched release
composer require auth0/symfony:^5.9.0
composer update auth0/symfony

# Verify the installed version is 5.9.0 or later
composer show auth0/symfony | grep versions