REDHAT-BUG-2545797: SSRF
A Blind Server-Side Request Forgery (SSRF) vulnerability was discovered in Keycloak within the org.keycloak.services.x509 component. When the X.509 client-certificate authenticator is enabled with CRL Distribution Point (CRLDP) or OCSP revocation checking, Keycloak attempts to fetch the CRL and OCSP responder URLs embedded in the presented client certificate before performing trust revalidation. An unauthenticated attacker can exploit this by presenting a crafted certificate containing attacker-controlled URLs in the CRL-DP or OCSP Authority Information Access (AIA) extensions. This induces the Keycloak server to initiate outbound HTTP GET or POST requests to arbitrary internal or external endpoints. A secondary exploitation vector exists when a proxy-header cert-lookup provider is configured with proxy-trusted-addresses unset, allowing the attack to be performed via plain HTTP headers without a valid TLS connection. Successful exploitation allows an attacker to probe internal network resources or interact with internal services that are otherwise unreachable from the outside.
Affected Software
Event History
Frequently Asked Questions
Which deployments are exposed to this issue?
Deployments are exposed when the X.509 client-certificate authenticator is enabled and uses CRL Distribution Point or OCSP revocation checking. A separate path is exposed when a proxy-header certificate-lookup provider is configured with proxy-trusted-addresses unset.
What must an attacker provide to trigger outbound requests?
For the X.509 authenticator path, an unauthenticated attacker presents a crafted client certificate containing attacker-controlled CRL-DP or OCSP AIA URLs. For the proxy-header path, the attacker can supply certificate data through plain HTTP headers when the affected proxy trust setting is unset.
How can an administrator determine whether their configuration is affected?
Review whether the X.509 client-certificate authenticator has CRLDP or OCSP revocation checking enabled. Also review proxy-header certificate lookup settings and identify configurations where proxy-trusted-addresses is unset.
What can be changed if remediation cannot be applied immediately?
Disable CRLDP and OCSP revocation checking in the X.509 client-certificate authenticator where operationally feasible. If using proxy-header certificate lookup, set proxy-trusted-addresses rather than leaving it unset.