CVE-2026-82756: ash_authentication_oauth2_server interpolates a tenant-derived value into the WWW-Authenticate challenge without escaping, allowing header parameter injection
Improper Encoding or Escaping of Output vulnerability in ash-project ashauthenticationoauth2server allows an unauthenticated attacker to inject arbitrary authentication parameters into the WWW-Authenticate challenge header.
BearerPlug and RequireScopePlug built the Bearer resourcemetadata="..." challenge by interpolating a resourcemetadata URL derived from the request tenant directly into the quoted value. In a multi-tenant application that sets the Ash tenant from request-controlled data (a subdomain, the Host, a path segment, or a header), a tenant containing a " closes the quoted value and appends attacker-chosen auth-params, including a second resourcemetadata URL pointing at an attacker-controlled authorization server that spec-following clients follow. Carriage returns and line feeds are rejected by Plug, so this is parameter injection within one header, not response splitting.
This issue affects ashauthenticationoauth2server: from 0.1.3 before 0.3.1.
Affected Software
Event History
Frequently Asked Questions
Which deployments are exposed in practice?
Exposure requires a multi-tenant application that derives the Ash tenant from request-controlled input, such as a subdomain, Host header, path segment, or request header, and uses BearerPlug or RequireScopePlug. Applications not using these plugs or not allowing request-controlled tenant selection are not described as having this attack path.
Does exploitation require authentication or response-splitting primitives?
No authentication is required. The attacker needs to supply a tenant value containing a double quote to terminate the quoted parameter; Plug rejects carriage returns and line feeds, so the issue is limited to authentication-parameter injection within a single header.
What is the practical client-side impact of injected parameters?
An attacker can append authentication parameters, including a second resource_metadata URL that points to an attacker-controlled authorization server. The described follow-on impact depends on spec-following clients following that injected URL.
Which versions should be upgraded?
The issue affects ash_authentication_oauth2_server versions from 0.1.3 before 0.3.1. Upgrade to 0.3.1 or later.