CVE-2025-11537: 
Java vulnerability analysis and mitigation

CVE-2025-11537 is an information disclosure vulnerability in Keycloak (keycloak-quarkus-server) where verbose logging patterns expose sensitive HTTP headers — including Authorization and Cookie — in cleartext log files. The flaw affects versions of org.keycloak:keycloak-quarkus-server prior to 26.5.6 and was published on February 10, 2026. It carries a CVSS v3.1 base score of 5.0 (Medium), requiring local access, low privileges, and user interaction (GitHub Advisory, Red Hat Bugzilla).

The root cause is classified as CWE-117 (Improper Output Neutralization for Logs): when Keycloak's logging format is set to a verbose, user-supplied pattern — such as the pre-defined long pattern — the HTTP access log includes full request headers without sanitization or masking. This causes sensitive headers like Authorization (bearing OAuth2/OIDC bearer tokens) and Cookie (containing session identifiers) to be written to log files in plaintext. Exploitation requires that an attacker already has read access to the Keycloak server's log files, and that an administrator has configured a verbose logging pattern (GitHub Advisory, Red Hat Bugzilla).

An attacker with read access to Keycloak log files can extract bearer tokens and session cookies logged in cleartext, then replay these credentials to impersonate legitimate users and achieve full account compromise. Because Keycloak acts as a central identity provider for many downstream applications, credential theft from logs could enable unauthorized access to all Keycloak-protected resources across an organization. Integrity and availability are not directly impacted; the primary risk is high confidentiality loss (GitHub Advisory).

1. Identify target configuration: Confirm that the Keycloak instance is running with a verbose logging pattern (e.g., the long pattern) by reviewing server configuration files or documentation at https://www.keycloak.org/server/logging#_change_log_formatpattern.
2. Gain log file read access: Obtain read access to Keycloak's HTTP access log files through insider access, a misconfigured file permission, a compromised service account, or another vulnerability that allows file system access.
3. Extract sensitive headers: Search log files for lines containing Authorization: Bearer <token> or Cookie: <session_id> entries written by the verbose logging pattern.
4. Replay credentials: Use the extracted bearer token or session cookie in crafted HTTP requests (e.g., via curl or a browser developer tool) to authenticate as the victim user against Keycloak or any downstream application protected by the same identity provider.
5. Achieve account compromise: With a valid session, perform actions on behalf of the impersonated user, access protected resources, or escalate privileges within the Keycloak-managed environment (GitHub Advisory, Red Hat Bugzilla).

• Logs: Keycloak HTTP access log entries containing Authorization: Bearer or Cookie: header values in plaintext when the long or other verbose logging pattern is active.
• File System: Unexpected access or modification timestamps on Keycloak log files (e.g., /var/log/keycloak/ or application-specific log directories) by non-administrative accounts.
• Logs: Authentication events in Keycloak audit logs showing logins from unusual IP addresses or user agents immediately following periods when log files were accessed.
• Network: Outbound requests using bearer tokens or session cookies originating from IP addresses not associated with the legitimate user's known locations, potentially indicating token replay attacks.

Patched versions are available: 26.4.11, 26.5.6, and 26.6.0 — upgrading to any of these releases is the recommended remediation (GitHub Advisory). As an immediate workaround, administrators should review and change the Keycloak logging format away from verbose patterns (such as long) that include full HTTP headers; the Keycloak logging documentation provides guidance on configuring log format/pattern. Additionally, restrict read access to Keycloak log files to only authorized administrative accounts, and consider implementing log filtering or masking to prevent sensitive headers from being written to disk in cleartext.

The vulnerability was reported internally via Red Hat's OSIDB system in October 2025 and publicly disclosed in February 2026 (Red Hat Bugzilla). A brief technical write-up was published by Infinit Security covering the nature of the header exposure (Infinit Security). No significant broader media coverage or notable researcher commentary beyond standard vulnerability database entries has been observed.