CVE-2026-82757 in ash_authentication_oauth2_server
Summary
by MITRE • 09/08/2026
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.
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 09/08/2026
The vulnerability identified as Server-Side Request Forgery in the ash_project ash_authentication_oauth2_server package represents a critical failure in network access control logic, specifically within the client metadata fetching mechanism. This flaw allows an attacker who controls both the DNS records and the content of a client metadata URL to manipulate the server into making HTTP requests to internal or loopback addresses that are typically restricted by security policies. The core issue lies in the implementation of the outbound policy enforcement within the ReqFetcher module, which is responsible for validating URLs before initiating network connections. By exploiting this misconfiguration, an attacker can bypass intended restrictions and potentially access sensitive internal services, read local configuration files, or interact with other resources on the host machine that are not exposed to the public internet.
The technical root cause of this vulnerability stems from an incomplete validation logic in the public_ip? function located within AshAuthentication.Oauth2Server.CIMD.ReqFetcher. This function is designed to classify IP addresses as either publicly routable or private/internal, thereby enforcing a whitelist-based approach for outbound connections. However, the implementation fails to correctly identify several specific IPv6 address ranges that are reserved for internal use but were incorrectly classified as public. Specifically, the code erroneously treats IPv4-compatible IPv6 addresses in the ::/96 range, such as ::127.0.0.1 which maps directly to localhost, as valid public endpoints. Additionally, it fails to block SIIT IPv4-translated addresses within the ::ffff:0:0:0/96 prefix and deprecated site-local addresses in the fec0::/10 range. Because these address forms are technically valid IPv6 formats but logically represent private or loopback destinations, their classification as public allows them to pass the security filter unchecked.
The operational impact of this vulnerability is significant for any deployment relying on OAuth2 authentication flows where client metadata URLs are fetched dynamically from external sources. If an attacker controls a DNS entry and serves malicious metadata pointing to one of these misclassified IPv6 addresses, the server will proceed with the request without raising an error or blocking the connection. This can lead to information disclosure if internal services respond with sensitive data, such as database credentials or session tokens stored in local files accessible via localhost endpoints. In more severe scenarios involving cloud environments or containerized deployments, this could facilitate lateral movement by allowing the attacker to probe and interact with other containers or virtual machines on the same network segment that are only reachable through loopback or internal interfaces. The vulnerability effectively neutralizes the security boundary intended by the SSRF mitigation strategy, turning a protective measure into an attack vector.
This issue is categorized under CWE-918, which defines Server-Side Request Forgery (SSRF) flaws where server-side code makes requests to user-supplied URLs without sufficient validation of the destination address. Furthermore, it aligns with MITRE ATT&CK technique T1557, specifically Adversary-in-the-Middle or Lateral Tool Transfer scenarios where internal network reconnaissance is conducted through compromised services. The failure to properly validate IPv6 address spaces highlights a common oversight in security implementations that may focus heavily on standard IPv4 ranges while neglecting the complexities of dual-stack environments and newer IP protocols. Such oversights can be particularly dangerous as they often go undetected by basic scanners that primarily test against known private IPv4 blocks like 10.x.x.x or 192.168.x.x, missing the more obscure but equally dangerous IPv6 variants.
To mitigate this vulnerability, organizations must upgrade to ash_authentication_oauth2_server version 0.3.1 or later, where the public_ip? function has been corrected to properly reject these specific IPv6 ranges. Until an update is applied, administrators should implement strict network-level controls such as egress filtering at the firewall or proxy level to block outbound connections to any non-public IP addresses, including all IPv6 reserved blocks. Additionally, it is advisable to review and harden DNS configurations for OAuth2 client metadata endpoints to ensure they cannot be hijacked by external parties. Security teams should also conduct thorough code reviews focusing on network validation logic in authentication modules, ensuring that both IPv4 and IPv6 address spaces are comprehensively validated against a deny-list of private ranges rather than relying solely on positive identification of public addresses. Regular penetration testing with tools capable of probing IPv6 SSRF vectors is recommended to detect similar implementation gaps in other services.