CVE-2024-9666

What it actually does

Keycloak, when configured to trust incoming proxy headers, fails to validate that forwarded client addresses are IP literals. Non-IP values such as hostnames or obfuscated identifiers are accepted and trigger synchronous DNS resolution on request-handling IO threads, which can be exhausted and stall the server (availability-only; no confidentiality or integrity impact).

Why it matters to the business

A successful attack can take down or severely slow the identity provider, interrupting logins, token issuance, and any applications that depend on Keycloak for SSO. Exploitability is constrained (local vector, high complexity, low privileges, reverse-proxy misconfiguration required), EPSS is low and flat (~0.004 with no 30-day movement), it is not in CISA KEV, ransomware use is not reported, and public exploit maturity is none—so mass opportunistic risk is limited, but an identity-plane outage remains operationally severe wherever proxy-header trust is enabled.

How an attack unfolds

An attacker who can already send HTTP requests to a Keycloak instance that trusts proxy headers—typically because a reverse proxy does not overwrite client-supplied Forwarded or X-Forwarded-* headers—includes non-IP values in those headers. Keycloak treats the values as addresses and performs DNS lookups. Repeated or crafted values cause expensive or hanging resolutions that occupy IO threads until new authentications and admin traffic stall. No named threat actors or campaigns are associated with this CVE.

How to fix it

Upgrade Keycloak (and Red Hat build of Keycloak / RH-SSO packages that ship this server) to the vendor-patched release for your stream; do not apply the unrelated Wireshark Ubuntu package versions that may appear in mis-mapped advisories. Until patched: disable proxy-header trust if Keycloak is not behind a reverse proxy; if it is, configure the proxy to strip and overwrite Forwarded, X-Forwarded-For, X-Forwarded-Host, and X-Forwarded-Proto so clients cannot supply them; restrict who can reach Keycloak to the proxy only; and avoid exposing the server on networks where untrusted clients can set those headers.

How to confirm the fix worked

Inventory Keycloak/RH-SSO instances and confirm they are on a vendor-fixed build. Review server config (proxy-headers / proxy-address-forwarding / trusted proxy settings) and the reverse-proxy config to prove client-supplied forwarded headers are overwritten. Confirm the listener is not reachable except via that proxy. After change, watch startup and access logs for continued trust of raw client headers and verify DNS query volume from the Keycloak process does not spike in lockstep with inbound requests. Do not run denial-of-service tests against production.

Typical attack path

1. Gain the ability to send HTTP requests to a Keycloak endpoint (local/low-privilege path consistent with the scoring).
2. Identify that Keycloak is configured to accept/trust proxy headers and that the front-end proxy does not overwrite incoming Forwarded or X-Forwarded-* headers.
3. Submit requests whose trusted proxy headers contain non-IP identifiers instead of addresses.
4. Force Keycloak to perform costly DNS resolution on IO threads.
5. Repeat or sustain the requests until request threads are tied up and authentication/admin services become unavailable.

How to detect it

There is no public in-the-wild exploitation and no associated threat actors, so hunt for attempted abuse and residual misconfiguration rather than a known campaign. Review Keycloak/HTTP access logs for Forwarded or X-Forwarded-For/Host values that are not IP addresses; correlate with DNS resolver logs and process-level DNS from the Keycloak/Java service showing bursts of lookups timed with those requests; inspect thread dumps or metrics for IO threads blocked in name resolution; and check reverse-proxy logs for clients that still supply forwarded headers that were not overwritten. Availability symptoms are thread starvation, login timeouts, and elevated event-loop delay without a corresponding CPU-bound workload.

• X-Forwarded-For:
• X-Forwarded-Host:
• Forwarded: for=
• Forwarded: host=
• proxy-address-forwarding
• proxy-headers
• blocked in InetAddress
• UnknownHostException
• vertx-eventloop
• io.quarkus.vertx

What your security team should do

• Patch Keycloak/RH-SSO to the vendor-fixed version for each deployed stream as the primary fix.
• Immediately disable trust of proxy headers on any instance not strictly behind a rewriting reverse proxy.
• Harden reverse proxies to overwrite Forwarded and X-Forwarded-* headers and restrict Keycloak listeners to proxy-only networks.
• Prioritize internet-facing or shared-ingress IdP nodes even though CVSS is moderate, because availability of SSO is business-critical.
• Treat this as configuration hygiene plus patching; do not delay on the basis of low EPSS or non-KEV status if proxy-header trust is enabled.