CVE-2026-82757: ash_authentication_oauth2

CVE-2026-82757 Overview

CVE-2026-82757 is a Server-Side Request Forgery (SSRF) vulnerability in the ash-project/ash_authentication_oauth2_server library for Elixir. The flaw resides in the Client Initiated Metadata Discovery (CIMD) request fetcher, which enforces an outbound network policy to block internal targets. The public_ip?/1 function in AshAuthentication.Oauth2Server.CIMD.ReqFetcher misclassifies several IPv6 address forms as publicly routable. An attacker who controls both a client metadata URL and its DNS resolution can return a crafted AAAA record that bypasses the SSRF guard and cause the server to connect to loopback or internal addresses. The issue affects ash_authentication_oauth2_server from 0.3.0 before 0.3.1 and is tracked under [CWE-918].

Critical Impact
An attacker who controls DNS for a client metadata URL can force the OAuth2 server to issue outbound requests to internal or loopback services, enabling reconnaissance and interaction with unauthenticated internal HTTP endpoints.

Affected Products

ash-project/ash_authentication_oauth2_server version 0.3.0
All releases of ash_authentication_oauth2_server prior to 0.3.1
Elixir applications using the CIMD metadata fetcher (AshAuthentication.Oauth2Server.CIMD.ReqFetcher)

Discovery Timeline

2026-09-07 - CVE-2026-82757 published to NVD
2026-09-08 - Last updated in NVD database

Technical Details for CVE-2026-82757

Vulnerability Analysis

The ash_authentication_oauth2_server library implements CIMD to fetch OAuth2 client metadata from URLs supplied by clients. To prevent SSRF, the fetcher pins the connection to a resolved IP and validates the address using public_ip?/1. The validator explicitly denied :: and ::1, then defaulted to treating remaining IPv6 addresses as public.

The defaulting behavior was the flaw. Three IPv6 address classes that carry embedded or loopback-adjacent semantics were not re-mapped to the IPv4 policy before the public check. As a result, a DNS response containing an AAAA record such as ::127.0.0.1 passed validation, and the HTTP client then dialed the pinned IPv6 address, which routes to the loopback interface on most stacks.

Root Cause

The IPv6 branch of public_ip?/1 only recognized ::ffff:a.b.c.d (IPv4-mapped) and 64:ff9b::/96 (NAT64) as embedded-IPv4 forms that require re-checking against the IPv4 policy. It missed three ranges:

::/96 — IPv4-compatible IPv6 addresses such as ::127.0.0.1
::ffff:0:0:0/96 — SIIT IPv4-translated addresses
fec0::/10 — deprecated site-local addresses

Any AAAA record in these ranges was classified as public and permitted by the outbound policy.

Attack Vector

Exploitation requires the attacker to register a hostname whose AAAA record they control. The attacker submits a CIMD client metadata URL that resolves to, for example, ::127.0.0.1. The fetcher validates the address, the check returns true, and the connection is established against the server's own loopback interface. The same technique enables reaching site-local IPv6 destinations on internal networks. Confidentiality and integrity of the OAuth2 server itself are not directly impacted, but downstream systems reachable only from the server become addressable.

text

            (a == 255 and b == 255 and c == 255 and d == 255))
   end
 
-  def public_ip?({w1, w2, w3, w4, w5, w6, w7, w8} = ip) do
+  def public_ip?({w1, w2, w3, w4, w5, w6, w7, w8}) do
     cond do
-      # :: and ::1
-      ip in [{0, 0, 0, 0, 0, 0, 0, 0}, {0, 0, 0, 0, 0, 0, 0, 1}] ->
-        false
+      # ::/96 — IPv4-compatible (incl. :: and ::1); re-check the embedded IPv4.
+      # `::127.0.0.1` and friends live here, so this must map to the v4 policy
+      # rather than fall through as "public".
+      {w1, w2, w3, w4, w5, w6} == {0, 0, 0, 0, 0, 0} ->
+        public_ip?(embedded_v4(w7, w8))
 
       # ::ffff:a.b.c.d — IPv4-mapped; re-check the embedded IPv4
       {w1, w2, w3, w4, w5} == {0, 0, 0, 0, 0} and w6 == 0xFFFF ->
         public_ip?(embedded_v4(w7, w8))
 
+      # ::ffff:0:a.b.c.d (::ffff:0:0:0/96) — SIIT IPv4-translated; re-check the
+      # embedded IPv4. Distinct from the mapped form above by w5/w6.
+      {w1, w2, w3, w4} == {0, 0, 0, 0} and w5 == 0xFFFF and w6 == 0 ->
+        public_ip?(embedded_v4(w7, w8))
+
       # 64:ff9b::/96 — NAT64; re-check the embedded IPv4
       {w1, w2, w3, w4, w5, w6} == {0x64, 0xFF9B, 0, 0, 0, 0} ->
         public_ip?(embedded_v4(w7, w8))

Source: GitHub Commit 268b591. The patch remaps ::/96, ::ffff:0:0:0/96 (SIIT), and adds handling so IPv4-compatible addresses are re-evaluated under the IPv4 policy rather than being treated as public.

Detection Methods for CVE-2026-82757

Indicators of Compromise

Outbound HTTP requests from the OAuth2 server process to IPv6 destinations in ::/96, ::ffff:0:0:0/96, or fec0::/10.
DNS resolutions from the server for attacker-controlled hostnames returning AAAA records that encode loopback or RFC1918 addresses (for example ::127.0.0.1).
CIMD metadata fetch log entries referencing unexpected client metadata URLs originating from untrusted clients.

Detection Strategies

Instrument AshAuthentication.Oauth2Server.CIMD.ReqFetcher to log the resolved address alongside the requested hostname, and alert when the resolved family is IPv6 and falls into the previously misclassified ranges.
Enable egress flow logging on the host running the OAuth2 server and correlate outbound connections to loopback or link-local IPv6 destinations with process identity.
Review web server access logs for CIMD requests carrying metadata URLs whose hostnames do not appear in prior traffic baselines.

Monitoring Recommendations

Continuously monitor DNS responses observed by the server for AAAA records matching ::0:0:0:0:0:0:x:y, ::ffff:0:x:y, or fec0::/10.
Track the running version of ash_authentication_oauth2_server across deployments and alert on any instance still at 0.3.0.
Audit which OAuth2 clients are permitted to trigger CIMD metadata fetches, and flag new client registrations with externally hosted metadata URLs.

How to Mitigate CVE-2026-82757

Immediate Actions Required

Upgrade ash_authentication_oauth2_server to version 0.3.1 or later in all deployments.
Restrict which OAuth2 clients can register or update CIMD metadata URLs until the upgrade is complete.
Apply egress firewall rules on the OAuth2 server host to block outbound connections to loopback, RFC1918, and site-local IPv6 ranges.

Patch Information

The upstream fix ships in ash_authentication_oauth2_server0.3.1. The change is documented in GitHub Security Advisory GHSA-wprp-8gvj-p6cv and implemented in commit 268b591. Additional details are available in the CNA advisory and the OSV record EEF-CVE-2026-82757.

Workarounds

Disable CIMD metadata fetches for untrusted or externally supplied client metadata URLs until the patch is applied.
Deploy a network-level SSRF filter that resolves the destination hostname, rejects AAAA records in ::/96, ::ffff:0:0:0/96, and fec0::/10, and forwards only vetted traffic to the OAuth2 server.
Bind the server to an environment where the loopback interface does not expose sensitive services, reducing the value of any SSRF that reaches 127.0.0.1.

bash

# Update the Elixir dependency in mix.exs and refresh the lock file
# mix.exs
#   {:ash_authentication_oauth2_server, "~> 0.3.1"}
mix deps.update ash_authentication_oauth2_server
mix deps.get
mix compile

CVE-2026-82757: ash_authentication_oauth2_server SSRF Vulnerability