ash_authentication_oauth2_server CVE-2026-82755

Exploitation requires all of the following conditions simultaneously: (1) the deployment is multi-tenant, (2) tenant identity is derived from something other than the URL - specifically a request header (e.g., X-Tenant-ID) or the HTTP Host header - so that two tenants share the same /.well-known/ URL, and (3) a shared HTTP cache (CDN, reverse proxy with caching, or similar) sits between clients and the Phoenix application. Single-tenant deployments are not affected because there is only one tenant's metadata. Deployments where tenant routing is embedded in the URL path or subdomain (and the cache key therefore differs per tenant) are not affected. The attack requires no authentication, no user interaction, and no attacker-controlled network position - it occurs passively when the first tenant's response is stored by the cache and served to the second tenant.

The CVSS 4.0 base score of 6.3 with vector AV:N/AC:L/AT:P/PR:N/UI:N/VC:L/VI:N/VA:N/SC:L/SI:L/SA:N is accurate and well-calibrated: AT:P (specific attack requirement: a shared cache must be present) is the key gating condition, correctly preventing inflation to a higher score. For deployments that do use a shared cache (CDN, Nginx proxy_cache, Varnish) in front of a header-routed multi-tenant instance, the practical risk is meaningfully higher than the raw score suggests - the attack is passively triggered by normal traffic, requires no attacker credentials, and persists for the full cache TTL (up to 1 hour). The integrity and confidentiality impact on subsequent systems (SC:L/SI:L) reflects the real downstream harm: OAuth clients that trust poisoned discovery metadata may silently redirect sensitive grant artifacts (authorization codes, refresh tokens) to an adversary-controlled or wrong-tenant endpoint. No public exploit code is known and no active exploitation has been identified. EPSS data is not available in the provided input. The attack is opportunistic for any tenant whose first request to the shared URL is cached under another tenant's response - no deliberate attacker action is required beyond being the second tenant to hit the endpoint after a cache warm.

A multi-tenant SaaS platform running ash_authentication_oauth2_server 0.1.3 routes tenant identity via a custom X-Tenant-ID header and places Nginx with proxy caching in front of the Phoenix application. When a client for tenant-A requests /.well-known/oauth-authorization-server, the response - containing tenant-A's token endpoint - is stored in the shared cache. When a client for tenant-B subsequently requests the same URL, Nginx serves the cached tenant-A metadata. Tenant-B's OAuth client then sends its authorization code to tenant-A's token endpoint, where it may be consumed by tenant-A's authorization server or an attacker monitoring tenant-A's traffic. No exploit code is required; the attack occurs passively through normal cache behavior.