OpenAM EUVD-2026-92026

Requires an authenticated attacker who holds the privilege to register or modify OAuth 2.0 / OpenID Connect clients in OpenAM (PR:L) - self-service or dynamic client registration being enabled materially widens this. The SSRF is triggered specifically through the OIDC client-authentication and ID-token validation paths that dereference the client's jwks_uri, so OpenAM must be acting as an OAuth2/OIDC authorization server with those flows in use. Realistic impact also depends on OpenAM's network position: the fetch only reaches internal hosts, cloud metadata endpoints, or local files that the OpenAM server itself can route to. Limiting factors: requires client-management privileges (not fully unauthenticated), affects only versions before 16.1.3, and yields only low-impact read/probe plus thread-exhaustion DoS rather than direct code execution.

This is a medium-severity SSRF (CWE-918) in Open Identity Platform OpenAM before 16.1.3, scored CVSS 4.0 5.3. The provided CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:L/UI:N/VC:L/VI:N/VA:L) indicates a network-reachable, low-complexity attack that requires low-level privileges (PR:L) - consistent with the description's requirement that the attacker be 'able to register or modify OAuth 2.0 clients.' Impact is bounded: low confidentiality (probing internal hosts/metadata/local files) and low availability (thread exhaustion DoS), with no integrity impact and no scope/subsequent-system impact (SC:N/SI:N/SA:N). No EPSS score, KEV listing, or public POC is present in the provided data, so there is no evidence of active or at-scale exploitation; the only sources are the GHSA and VulnCheck advisories (disclosure, not exploit code). Net: this is a legitimate but not top-priority issue - the PR:L authentication requirement and the lack of exploitation signals (no KEV, no EPSS, no POC) argue against emergency patching, though the unauthenticated-fetch primitive it grants (attacker-controlled client triggers OpenAM-side fetches) makes it valuable in environments where OpenAM can reach sensitive internal networks or cloud metadata endpoints. EPSS is absent rather than low, so exploitation probability cannot be quantified from the provided data.

An attacker with the ability to register or modify an OAuth 2.0 client in OpenAM sets a malicious jwks_uri pointing at an internal address (e.g., a cloud metadata endpoint, an internal admin host, or a local file). When OpenAM performs client-authentication or ID-token validation, it fetches that unvalidated URI server-side, letting the attacker probe internal resources or exhaust request threads for denial of service. No public exploit code is identified in the provided data, so exploitation would require custom tooling.