CVE-2026-82755 in ash_authentication_oauth2_server
Summary
by MITRE • 09/08/2026
Use of Cache Containing Sensitive Information vulnerability in ash-project ash_authentication_oauth2_server allows a shared HTTP cache to serve one tenant's OAuth discovery metadata to another tenant's clients.
The RFC 8414 and RFC 9728 metadata endpoints in AshAuthentication.Phoenix.Oauth2Server.ProtocolRouter return tenant-specific values (issuer, authorization_endpoint, token_endpoint, jwks_uri) when a tenant is set, but sent them with Cache-Control: public, max-age=3600 and no Vary. When the tenant is derived from something other than the URL (a header or the Host) and a shared cache sits in front, the cache key is the URL alone, so a stored response for one tenant is served to another for up to an hour. Affected clients may then send authorization codes and secrets to the wrong tenant's token endpoint and validate tokens against the wrong keys.
This issue affects ash_authentication_oauth2_server: from 0.1.3 before 0.3.1.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 09/08/2026
The vulnerability identified in ash-project ash_authentication_oauth2_server represents a critical failure in cache control implementation within OAuth 2.0 and OpenID Connect discovery metadata endpoints, specifically those adhering to RFC 8414 and RFC 9728 standards. In multi-tenant SaaS architectures relying on this library, the server is designed to return tenant-specific configuration values such as the issuer URL, authorization endpoint, token endpoint, and JSON Web Key Set URI based on the identified tenant context. However, the implementation incorrectly sets the Cache-Control header to public with a max-age of 3600 seconds while omitting any Vary headers that would account for tenant-identifying factors like HTTP Host or custom authentication headers. This configuration instructs shared intermediate caches and CDNs to store and serve these responses based solely on the request URL, ignoring the contextual differences between tenants who may share identical endpoint paths but differ in identity attributes.
From a technical perspective, this flaw constitutes an improper cache key generation mechanism that leads to sensitive information leakage across tenant boundaries. When a client from Tenant A requests the discovery metadata, the response is cached by intermediate proxies with a one-hour validity period. If a subsequent request arrives for Tenant B using the same URL path but different host or header-based tenant identification, the shared cache serves the previously stored response intended for Tenant A without re-validating it against the new context. This behavior violates fundamental principles of secure multi-tenancy where data isolation is paramount. The absence of Vary headers such as Host or Authorization means that caching systems treat distinct logical tenants as identical requests, thereby breaching confidentiality and integrity requirements inherent in OAuth 2.0 flows.
The operational impact of this vulnerability is severe, potentially leading to complete authentication bypass and unauthorized access across tenant boundaries. Clients configured with the poisoned discovery metadata will direct their authorization code grants and client secrets to Tenant A’s token endpoint instead of Tenant B’s. Consequently, tokens issued for Tenant A may be accepted by applications expecting credentials from Tenant B if key sets are misaligned or if validation logic relies on cached JWKS data that does not match the actual tenant's public keys. This can result in attackers impersonating users from one tenant within another tenant's application environment. Furthermore, since OAuth discovery metadata is often cached aggressively for performance reasons, this issue persists for up to an hour, providing a wide window of opportunity for exploitation without requiring continuous active attacks against each individual request.
This vulnerability aligns with CWE-524, which describes the use of cache containing sensitive information, and falls under MITRE ATT&CK technique T1078, specifically relating to valid accounts used in unauthorized contexts or misconfigured authentication systems that allow cross-context data leakage. It also reflects weaknesses associated with improper input validation regarding caching directives, often categorized under CWE-525 or related HTTP header manipulation flaws. The root cause lies not in the logic of tenant resolution itself but in the failure to communicate cache variability requirements correctly to intermediary infrastructure, a common oversight in high-performance web application frameworks that prioritize speed over strict security isolation for metadata endpoints.
To mitigate this vulnerability, immediate remediation involves upgrading ash_authentication_oauth2_server to version 0.3.1 or later where these caching headers have been corrected. For environments unable to upgrade immediately, manual configuration of reverse proxies such as Nginx or Apache is required to enforce stricter cache policies on OAuth discovery endpoints. This includes setting Cache-Control: no-store or private with appropriate Vary headers that include Host and any custom tenant-identifying headers used by the application. Additionally, developers should audit other metadata endpoints for similar misconfigurations ensuring that all responses containing sensitive configuration data are either not cached at all or are strictly varied by all relevant request attributes to prevent cross-tenant contamination in shared caching layers.