EUVD-2026-77672
GHSA-ffq7-hh2j-r24p
Severity by source
AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N
PR:L reflects the mandatory valid bearer token prerequisite; C:H reflects full token disclosure enabling session impersonation; no integrity or availability impact applies.
Primary rating from Vendor (https://github.com/auth0/symfony).
CVSS VectorVendor: https://github.com/auth0/symfony
Lifecycle Timeline
2DescriptionCVE.org
Description
Applications built with the Auth0 Symphony SDK, using the Authorizer security authenticator to protect HTTP routes may accept OAuth 2.0 bearer access tokens provided through a URL query parameter, in addition to the standard Authorization header, which may increase the risk of access token exposure and replay against protected API endpoints.
Resolution
Upgrade auth0/symfony to version 5.9.0 or greater.
Acknowledgement
Okta would like to thank Alex Yeara for their discovery.
AnalysisAI
Token exposure in the Auth0 Symfony SDK (auth0/symfony) versions 5.0.0-BETA0 through 5.8.0 allows OAuth 2.0 bearer access tokens to be submitted via a URL query parameter (?token=) in addition to the standard Authorization header, violating RFC 6750 Section 2.3 guidance. Any Symfony application using the Authorizer security authenticator is affected, with tokens silently recorded in server access logs, CDN and proxy logs, browser history, and Referer headers - all outside the intended OAuth token trust boundary. No public exploit has been identified and the vulnerability is not in CISA KEV; however, the design flaw is trivially reproducible by any authenticated user and creates persistent, passive token leakage risk.
Technical ContextAI
The root cause is in src/Security/Authorizer.php of the auth0/symfony Composer package (pkg:composer/auth0/symfony, versions >= 5.0.0-BETA0 to <= 5.8.0). The Authorizer class, which acts as a Symfony security authenticator for HTTP route protection, contained logic to call $request->query->get('token') and use that value as a fallback when no Authorization header was present - accepting the token from either source interchangeably. CWE-200 (Exposure of Sensitive Information to an Unauthorized Actor) applies: URL query parameters are durably stored in web server access logs, reverse proxy and CDN logs, browser history, analytics pipelines, and outbound Referer headers, all of which are typically outside the trust boundary defined for bearer token handling. The OAuth 2.0 bearer token spec (RFC 6750) explicitly marks the URI query parameter method as 'SHOULD NOT' be used for this reason. The fix in commit 172d1d3e removes the $request->query->get('token') call entirely and enforces exclusive use of the Authorization header.
RemediationAI
Upgrade the auth0/symfony Composer package to version 5.9.0 or greater, confirmed fixed via two patch commits (172d1d3e0b9d1e93610d786118389a811179bc8a and bd1851b14ae15e99cbe87c96496cf25da025288a) and the 5.9.0 release tag. Update composer.json to require "auth0/symfony": "^5.9.0" and run composer update auth0/symfony. As a compensating control prior to patching, configure WAF or reverse proxy rules to reject inbound requests where a token query parameter is present on API endpoints - note this may break any integrations that were unintentionally relying on the query-parameter behavior, so test before deploying. Additionally, rotate any access tokens that may have been transmitted via query parameter, as copies may persist in server access logs, CDN logs, and browser histories; token rotation limits the replay window for any already-harvested credentials. Full advisory: https://github.com/auth0/symfony/security/advisories/GHSA-ffq7-hh2j-r24p.
Same weakness CWE-200 – Information Exposure
View allSame technique Information Disclosure
View allShare
External POC / Exploit Code
Leaving vuln.today