Ash Authentication Oauth2 Server
Approved changes feed: RSS · Atom
cpe:2.3:a:ash-project:ash_authentication_oauth2_server:*:*:*:*:*:*:*:*
part: a version: * update: *
| Vendor | Ash Project (decf2fe9-ca5e-5756-ba5a-f6ffc43cbfd9) |
|---|---|
| Product | Ash Authentication Oauth2 Server (a4dc7467-0626-5929-b4ef-55e41ab1da7b) |
| Edition | * |
| Language | * |
| Software edition | * |
| Target software | * |
| Target hardware | * |
| Other | * |
| Notes | Imported from gcve-enriched-dumps CVE data |
PURL mappings
| PURL | Source | Last updated |
|---|---|---|
| No PURL mappings for this CPE yet. | ||
Vulnerability references
| Identifier | cpeApplicability | Submitted | db.gcve.eu details | Rationale |
|---|---|---|---|---|
CVE:CVE-2026-82755 |
vulnerable | 2026-09-16 04:32:53.876574 |
ash_authentication_oauth2_server serves tenant-specific OAuth metadata as publicly cacheable without Vary, enabling cross-tenant confusion
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.
Published: 2026-09-07T22:28:24.500Z
Updated: 2026-09-08T14:42:17.718Z Reference links
|
Imported from gcve-enriched-dumps CVE data |
CVE:CVE-2026-82758 |
vulnerable | 2026-09-16 04:32:53.798452 |
ash_authentication_oauth2_server treats an empty resolved secret as valid, opening the gated Dynamic Client Registration endpoint
Improper Authentication vulnerability in ash-project ash_authentication_oauth2_server allows an unauthenticated attacker to register OAuth clients even when Dynamic Client Registration is gated by an initial access token.
resolve_secret/3 in AshAuthentication.Oauth2Server (reached through __resolve_secret__!) treated any return other than {:ok, _} or :error from a configured {module, function, args} or 2-arity-function secret provider as a valid secret, wrapping nil, false, or "" as {:ok, value}. When the initial_access_token resolves to such an empty value, POST /oauth/register compares the presented bearer token against it and the comparison passes with no token supplied, so registration is open although it was configured closed. The same fail-open affected other resolved secrets such as signing_secret.
This issue affects ash_authentication_oauth2_server: from 0.1.0 before 0.3.1.
Published: 2026-09-07T22:32:17.027Z
Updated: 2026-09-08T14:41:06.227Z Reference links
|
Imported from gcve-enriched-dumps CVE data |
CVE:CVE-2026-82754 |
vulnerable | 2026-09-16 04:32:53.785117 |
ash_authentication_oauth2_server aliases every protocol endpoint under /.well-known, bypassing path-scoped controls
Improper Protection of Alternate Path vulnerability in ash-project ash_authentication_oauth2_server exposes the state-changing OAuth endpoints under an unintended URL prefix, bypassing controls scoped to the canonical prefix.
oauth2_server_protocol_routes/1 in AshAuthentication.Phoenix.Oauth2Server.Router forwards the same ProtocolRouter at both the /oauth prefix and the /.well-known prefix. Phoenix forward strips the matched prefix before dispatch, so the full route table answers under both mounts, and POST /register, POST /token, and POST /revoke are reachable as /.well-known/register, /.well-known/token, and /.well-known/revoke. Edge controls such as WAF rules, rate limits, or authentication exemptions written against the /oauth paths, or that allow-list /.well-known as unauthenticated, do not apply to the alias.
This issue affects ash_authentication_oauth2_server: from 0.1.0 before 0.3.1.
Published: 2026-09-07T22:23:56.762Z
Updated: 2026-09-08T14:41:45.077Z Reference links
|
Imported from gcve-enriched-dumps CVE data |
CVE:CVE-2026-82756 |
vulnerable | 2026-09-16 04:32:53.709874 |
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 ash_authentication_oauth2_server allows an unauthenticated attacker to inject arbitrary authentication parameters into the WWW-Authenticate challenge header.
BearerPlug and RequireScopePlug built the Bearer resource_metadata="..." challenge by interpolating a resource_metadata 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 resource_metadata 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 ash_authentication_oauth2_server: from 0.1.3 before 0.3.1.
Published: 2026-09-07T22:30:55.280Z
Updated: 2026-09-08T14:43:33.571Z Reference links
|
Imported from gcve-enriched-dumps CVE data |
CVE:CVE-2026-82757 |
vulnerable | 2026-09-16 04:32:53.674264 |
ash_authentication_oauth2_server CIMD fetcher classifies IPv4-in-IPv6 and site-local addresses as public, allowing SSRF
Server-Side Request Forgery (SSRF) vulnerability in ash-project ash_authentication_oauth2_server allows an attacker who controls a client metadata URL and its DNS to make the server connect to internal or loopback addresses.
public_ip?/1 in AshAuthentication.Oauth2Server.CIMD.ReqFetcher enforces the outbound policy for CIMD metadata fetches. It classified several address forms as publicly routable that are not: IPv4-compatible ::/96 (for example ::127.0.0.1), SIIT IPv4-translated ::ffff:0:0:0/96, and deprecated site-local fec0::/10. A returned AAAA record in one of these ranges passed the policy, so a fetch pinned to that address reached space the policy was meant to block.
This issue affects ash_authentication_oauth2_server: from 0.3.0 before 0.3.1.
Published: 2026-09-07T22:31:34.656Z
Updated: 2026-09-08T14:43:57.511Z Reference links
|
Imported from gcve-enriched-dumps CVE data |
CVE:CVE-2026-82753 |
vulnerable | 2026-09-16 04:32:53.622181 | db.gcve.eu details were skipped to keep the page responsive. | Imported from gcve-enriched-dumps CVE data |
Contribute
You can submit an edit proposal for this CPE entry or suggest a related product/vendor addition using the action button above.