CVE-2026-105301: Keycloak-services: keycloak-services: blind ssrf via x.509 authenticator fetching attacker-controlled crl-dp/ocsp urls
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.
Other sources
A flaw was found in the X.509 client-certificate authenticator of Keycloak, a solution for identity and access management. The issue occurs when the server is configured to check certificate revocation using CRL Distribution Points or OCSP. An attacker can provide a specially crafted certificate that points to a malicious server, causing Keycloak to make unauthorized outbound requests to internal or external endpoints before the certificate is fully validated. This can lead to a blind server-side request forgery (SSRF) attack.
— MITRE
Affected Software
Event History
Frequently Asked Questions
Which Keycloak deployments are exposed to this issue?
Deployments are exposed when the X.509 client-certificate authenticator is enabled with CRL Distribution Point or OCSP revocation checking. A separate path is exposed when a proxy-header certificate lookup provider is configured and proxy-trusted-addresses is unset.
What does an attacker need to exploit the vulnerable certificate-authentication path?
An unauthenticated attacker needs to present a crafted client certificate containing attacker-controlled CRL Distribution Point or OCSP Authority Information Access URLs. Keycloak then fetches those URLs before trust revalidation.
Can this be exploited without a valid TLS client-certificate connection?
Yes, but only through the secondary vector: a proxy-header certificate lookup provider must be configured with proxy-trusted-addresses unset. In that configuration, the attack can be triggered through plain HTTP headers.
What impact can the attacker achieve?
The attacker can cause Keycloak to make outbound HTTP GET or POST requests to arbitrary internal or external endpoints. This can be used to probe internal network resources or interact with services not otherwise reachable externally.