CVE-2026-18212: Keycloak-services: keycloak-services: saml redirect deflate helpers leak native zlib state
A flaw was found in the SAML Redirect Binding implementation of Keycloak, an open-source identity and access management solution. The issue occurs because the custom DEFLATE compression and decompression helpers fail to release native zlib memory after use. An unauthenticated attacker can exploit this by sending repeated malformed SAML requests, leading to native memory exhaustion and a denial of service.
Other sources
A memory leak flaw was found in Keycloaks SAML Redirect Binding. The implementation uses custom Deflater and Inflater instances to handle DEFLATE compression and decompression for SAML artifacts. These Java classes allocate native memory via zlib that is not managed by the standard Java heap. The code fails to call the end method on these instances, which is required to explicitly release the native resources. An unauthenticated remote attacker can trigger this leak by sending specially crafted, malformed SAML Redirect requests to the Keycloak SAML endpoint. Because the native memory is not reclaimed by the Java garbage collector, repeated requests will cause the process resident set size (RSS) to grow until the operating system terminates the process due to memory exhaustion. Successful exploitation results in a complete denial of service for the Keycloak instance.
— Red Hat
Affected Software
Event History
Frequently Asked Questions
Which deployments are exposed to this denial-of-service condition?
Keycloak deployments with a reachable SAML Redirect Binding endpoint are exposed, because the issue can be triggered remotely through that endpoint. No authentication or user interaction is required.
What must an attacker send to trigger the memory leak?
An attacker sends repeated specially crafted malformed SAML Redirect requests. Each request can leave native zlib memory allocated, causing the Keycloak process RSS to grow over time.
Will Java garbage collection recover the leaked memory?
No. The affected Deflater and Inflater instances allocate native zlib memory, and the implementation does not call end() to explicitly release it; this memory is not reclaimed by standard Java heap garbage collection.
How does the issue affect the service when exploited?
Repeated requests can exhaust native memory until the operating system terminates the Keycloak process, resulting in denial of service.