Description

Auth0 Symfony is a Symfony SDK for Auth0 Authentication and Management APIs. From 5.0.0-BETA0 until 5.9.0, the Authorizer::authenticate() and Authorizer::supports() paths in the Authorizer security authenticator may accept OAuth 2.0 bearer access tokens from the token URL query parameter as well as the Authorization header for protected HTTP routes. Query-string tokens can be recorded in server logs, browser history, or referrer data and then replayed against protected API endpoints. This issue is fixed in version 5.9.0.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "6.5",
  "pubDate": "2026-09-14T18:17:49.663Z",
  "pubdate": "2026-09-14T18:17:49.663Z",
  "executiveSummary": "The Auth0 Symfony SDK is susceptible to an improper authentication implementation where sensitive OAuth 2.0 bearer access tokens are accepted via URL query parameters in addition to the standard Authorization header.\nThis vulnerability affects versions 5.0.0-BETA0 through 5.8.x of the Auth0 Symfony package. By allowing tokens in query strings, the system inadvertently facilitates the exposure of credentials to insecure logging mechanisms, browser history, and HTTP Referer headers.\nThe risk implication is significant, as attackers who gain access to these logs or intercepted traffic can effectively hijack authenticated sessions. The vulnerability requires no complex exploitation techniques, as it relies on the inadvertent leakage of tokens through common infrastructure components that log request URIs. The ability to replay captured tokens allows an attacker to bypass authentication controls and interact with protected API endpoints with the privileges of the victimized user. This poses a critical risk to data confidentiality and integrity for applications relying on the Authorizer component for security enforcement.",
  "technicalDetails": "The vulnerability originates within the Authorizer security authenticator, specifically residing in the Authorizer::authenticate() and Authorizer::supports() methods. These methods were designed to evaluate the authenticity of requests by inspecting incoming HTTP traffic for OAuth 2.0 bearer access tokens. However, the implementation lacks strict validation regarding the transport mechanism of these credentials.\nRoot Cause: The implementation fails to restrict token extraction exclusively to the 'Authorization: Bearer <token>' HTTP header, which is the industry-standard practice for secure API authentication. Instead, the authenticator processes tokens embedded directly within the URL query string. While this may have been intended for convenience or legacy compatibility, it violates RFC 6750 standards regarding the security of bearer token transmission.\nAttack Flow: When a client application includes an access token in a query parameter, the entire URL—containing the sensitive token—is typically logged by intermediate proxies, load balancers, web servers (such as Nginx or Apache), and application-level logging frameworks. Furthermore, if a user navigates to an external site or a sub-resource from a page containing this URL, the token is frequently transmitted in the 'Referer' header to the third-party server. An attacker gaining access to any of these logs or monitoring points can extract the bearer token. Once obtained, the attacker can replay the token against the vulnerable Auth0 Symfony-protected endpoint, effectively impersonating the legitimate user without requiring knowledge of original credentials.\nImpact Analysis: The exploitation does not require the attacker to possess elevated privileges initially; rather, they exploit the architectural oversight in token handling to assume the identity of an authenticated session. Because the tokens have a specific lifespan, any captured valid token provides the attacker with a window of opportunity to manipulate API resources or exfiltrate sensitive data, depending on the scope and permissions associated with the stolen access token.\nAffected Versions: This flaw exists in the Auth0 Symfony SDK from version 5.0.0-BETA0 up to and including 5.8.x. The issue was addressed and resolved in version 5.9.0, which enforces strict compliance by limiting token retrieval to the Authorization header, thereby mitigating the risk of inadvertent exposure through query-string logging."
}