CVE-2020-10770 Overview
A Server-Side Request Forgery (SSRF) vulnerability was discovered in Red Hat Keycloak versions prior to 13.0.0. The flaw exists in the OpenID Connect (OIDC) authentication flow, where the request_uri parameter can be manipulated to force the Keycloak server to make HTTP requests to arbitrary, unverified URLs. This vulnerability allows unauthenticated attackers to leverage the Keycloak server as a proxy to access internal resources, scan internal networks, or potentially interact with cloud metadata services.
Critical Impact
Unauthenticated attackers can exploit this SSRF vulnerability to access internal network resources, enumerate internal services, and potentially retrieve sensitive cloud metadata or configuration data through the compromised Keycloak server.
Affected Products
- Red Hat Keycloak versions prior to 13.0.0
- Keycloak 12.0.1 and earlier versions
Discovery Timeline
- 2020-12-15 - CVE-2020-10770 published to NVD
- 2024-11-21 - Last updated in NVD database
Technical Details for CVE-2020-10770
Vulnerability Analysis
This vulnerability exists in Keycloak's implementation of the OpenID Connect (OIDC) specification, specifically in how the request_uri parameter is processed during authentication requests. The OIDC specification allows clients to pass a request_uri parameter that points to a Request Object containing authorization request parameters. However, Keycloak fails to properly validate or restrict the URLs that can be specified in this parameter.
When an attacker supplies a malicious request_uri value, the Keycloak server will attempt to fetch the content from that URL without verifying that it points to a legitimate, trusted resource. This allows the attacker to make the server initiate outbound HTTP connections to arbitrary destinations, including internal network resources that would otherwise be inaccessible from the internet.
The vulnerability is classified under CWE-918 (Server-Side Request Forgery), as it allows attackers to abuse server functionality to access or modify internal resources.
Root Cause
The root cause of this vulnerability is insufficient input validation of the request_uri parameter in Keycloak's OIDC implementation. The server does not implement proper URL validation, allowlisting, or restrictions on the destinations that can be specified. This lack of validation allows external attackers to specify arbitrary URLs, including those pointing to internal network addresses, localhost services, or cloud metadata endpoints.
Attack Vector
The attack is network-based and requires no authentication or user interaction. An attacker can craft a malicious OIDC authentication request containing a request_uri parameter pointing to an internal resource. When Keycloak processes this request, it will attempt to fetch the content from the specified URL, effectively allowing the attacker to:
- Scan internal network services and ports
- Access cloud metadata services (e.g., AWS EC2 metadata at 169.254.169.254)
- Interact with internal APIs and services
- Potentially retrieve sensitive configuration data or credentials
The attack can be executed by sending a crafted HTTP request to the Keycloak authorization endpoint with a malicious request_uri parameter pointing to an internal or otherwise restricted resource. The server will fetch the content and potentially expose internal service responses through error messages or timing differences.
Detection Methods for CVE-2020-10770
Indicators of Compromise
- Unusual outbound HTTP requests from Keycloak servers to internal IP ranges (e.g., 10.x.x.x, 172.16.x.x, 192.168.x.x)
- HTTP requests from Keycloak to cloud metadata endpoints (169.254.169.254)
- Authorization endpoint requests containing request_uri parameters pointing to non-standard or internal URLs
- Unexpected network connections from Keycloak to localhost or loopback addresses
Detection Strategies
- Monitor Keycloak access logs for authorization requests containing suspicious request_uri parameter values
- Implement network-level monitoring to detect outbound connections from Keycloak servers to internal network segments
- Deploy Web Application Firewall (WAF) rules to detect and block OIDC requests with request_uri parameters containing internal IP addresses or known metadata endpoints
- Review Keycloak server logs for HTTP client errors indicating failed connections to unusual destinations
Monitoring Recommendations
- Enable detailed access logging on Keycloak servers to capture all OIDC request parameters
- Configure network segmentation and monitor east-west traffic from Keycloak servers
- Set up alerts for Keycloak servers making outbound connections to RFC 1918 private IP ranges
- Implement egress filtering to restrict outbound connections from Keycloak servers to known, trusted destinations
How to Mitigate CVE-2020-10770
Immediate Actions Required
- Upgrade Keycloak to version 13.0.0 or later, which includes a fix for this vulnerability
- If immediate upgrade is not possible, implement network-level controls to restrict outbound connections from Keycloak servers
- Deploy WAF rules to block or sanitize request_uri parameters in OIDC requests
- Review Keycloak server logs for evidence of exploitation attempts
Patch Information
Red Hat has addressed this vulnerability in Keycloak version 13.0.0 and later. Organizations should upgrade to the latest stable version of Keycloak to remediate this vulnerability. For detailed information about the fix, refer to the Red Hat Bug Report #1846270.
Additional technical details about the vulnerability and exploitation techniques are available in the Packet Storm Security Exploit publication.
Workarounds
- Implement strict network egress controls to prevent Keycloak servers from making outbound connections to internal network segments
- Configure firewall rules to block outbound HTTP/HTTPS connections from Keycloak servers to internal IP ranges and cloud metadata endpoints
- Deploy a Web Application Firewall (WAF) to filter and validate request_uri parameters in incoming OIDC requests
- If the request_uri functionality is not required, consider disabling or restricting this feature at the application or proxy level
# Example iptables rules to block outbound connections to internal networks and metadata endpoints
iptables -A OUTPUT -d 10.0.0.0/8 -j DROP
iptables -A OUTPUT -d 172.16.0.0/12 -j DROP
iptables -A OUTPUT -d 192.168.0.0/16 -j DROP
iptables -A OUTPUT -d 169.254.169.254 -j DROP
Disclaimer: This content was generated using AI. While we strive for accuracy, please verify critical information with official sources.

