CVE-2026-1180 is a medium-severity Server-Side Request Forgery (SSRF) vulnerability identified in Red Hat's build of Keycloak version 26.4. The vulnerability arises from improper validation in the OpenID Connect Dynamic Client Registration feature when clients authenticate using the private_key_jwt method. Specifically, the flaw allows a malicious client to specify an arbitrary JSON Web Key Set URI (jwks_uri) that Keycloak will fetch without validating whether the destination is trusted or safe. This behavior enables an attacker to coerce the Keycloak server into making HTTP requests to internal or restricted network resources that would otherwise be inaccessible externally. Such forced requests can be used to probe internal services, cloud metadata endpoints, or other sensitive infrastructure components, leading to information disclosure and reconnaissance opportunities for attackers. The vulnerability does not require any prior authentication or user interaction, increasing its risk profile. The CVSS v3.1 base score is 5.8, reflecting network attack vector, low attack complexity, no privileges required, no user interaction, and a scope change with limited confidentiality impact. No known exploits have been reported in the wild as of publication, and no patches or mitigations have been officially released by Red Hat at this time. However, the flaw represents a significant risk in environments where Keycloak is deployed as an identity provider, especially in cloud or segmented network architectures where internal endpoints must remain protected from unauthorized access. The vulnerability highlights the importance of validating external URIs in dynamic client registration workflows to prevent SSRF attacks.

The primary impact of CVE-2026-1180 is information disclosure and reconnaissance within an organization's internal network or cloud infrastructure. By exploiting this SSRF vulnerability, attackers can leverage the Keycloak server as a proxy to access internal services that are not exposed externally, including sensitive APIs, databases, or cloud metadata endpoints that may contain credentials or configuration data. This can facilitate further attacks such as privilege escalation, lateral movement, or data exfiltration. The vulnerability does not directly allow code execution or denial of service but significantly increases the attack surface by exposing internal resources. Organizations using Keycloak 26.4 in critical environments, especially those with strict network segmentation or cloud deployments, face elevated risk. The absence of authentication requirements and user interaction lowers the barrier for exploitation, potentially enabling automated scanning or targeted attacks. Although no active exploits are currently known, the vulnerability could be leveraged by attackers to gather intelligence for subsequent attacks, making it a strategic risk for enterprises relying on Keycloak for identity and access management.

Until an official patch is released by Red Hat, organizations should implement the following specific mitigations: 1) Restrict network egress from the Keycloak server to only trusted and necessary endpoints using firewall rules or network segmentation to prevent unauthorized outbound HTTP requests. 2) Implement strict validation and allowlisting of jwks_uri values during client registration to ensure only trusted URIs are accepted, potentially by disabling dynamic client registration if not required. 3) Monitor Keycloak logs for unusual outbound requests or client registrations specifying unexpected jwks_uri values to detect potential exploitation attempts. 4) Use Web Application Firewalls (WAFs) or Intrusion Detection Systems (IDS) to detect and block SSRF patterns targeting Keycloak. 5) Review and harden cloud metadata service access controls to prevent unauthorized retrieval even if SSRF occurs. 6) Plan for rapid deployment of patches once available and test updates in staging environments. 7) Educate developers and administrators about the risks of SSRF in dynamic client registration workflows to avoid similar issues in future configurations.