Am I affected?
Description
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.
Weaknesses & attack patterns
Weakness
CWE-524
·
Use of Cache Containing Sensitive Information
in catalog →
MITRE ↗
Attack patterns
CAPEC-204
·
Lifting Sensitive Data Embedded in Cache
MITRE ↗
Affected — Hex / ash_authentication_oauth2_server Hex.pm ↗ Repository ↗
modules · source files · routines
Affected — GitHub / ash-project/ash_authentication_oauth2_server Repository ↗
modules · source files · routines
Configurations
Reachable only in a multi-tenant deployment where the tenant is derived from outside the request URL (a header or the Host) and a shared HTTP cache (CDN, reverse proxy) sits in front of the metadata endpoints.
References
Credits
CVSS breakdown
CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:L/VI:N/VA:N/SC:L/SI:L/SA:N