CVE-2025-11538: Keycloak JDWP Debug Mode RCE Vulnerability

CVE-2025-11538 Overview

CVE-2025-11538 affects Keycloak's server distribution when administrators enable debug mode via the --debug <port> flag. The distribution scripts bind the Java Debug Wire Protocol (JDWP) port to all network interfaces (0.0.0.0) by default. Any attacker on the same network segment can attach a remote debugger to the exposed port. Once attached, the attacker gains remote code execution inside the Keycloak Java Virtual Machine, running with the privileges of the Keycloak service account. The weakness is classified as [CWE-1327]: Binding to an Unrestricted IP Address.

Critical Impact

Adjacent-network attackers can attach to the exposed JDWP port, execute arbitrary code inside the Keycloak JVM, and compromise identity, authentication, and single sign-on infrastructure.

Affected Products

• Keycloak server distribution (Quarkus-based) with debug mode enabled
• Red Hat Build of Keycloak (see Red Hat Security Advisory RHSA-2025:21370)
• Red Hat Single Sign-On distributions covered by RHSA-2025:21371

Discovery Timeline

• 2025-11-13 - CVE-2025-11538 published to the National Vulnerability Database
• 2026-06-17 - Last updated in the NVD database

Technical Details for CVE-2025-11538

Vulnerability Analysis

Keycloak ships startup scripts (kc.sh for Linux and kc.bat for Windows) that configure the JVM debug agent when operators pass --debug. The scripts hardcode the debug listener address to 0.0.0.0:<port>, exposing JDWP on every interface reachable from the host. JDWP does not implement authentication. An attacker who reaches the port can load classes, invoke methods, read memory, and execute arbitrary Java code inside the running Keycloak process.

Because Keycloak brokers authentication, federation, and SSO tokens, code execution inside its JVM yields full control of identity flows. Attackers can forge tokens, extract signing keys, or pivot to downstream applications relying on Keycloak.

Root Cause

The root cause is an insecure default in the debug launcher logic. The scripts constructed DEBUG_ADDRESS="0.0.0.0:$DEBUG_PORT" instead of binding to loopback. Operators enabling debug mode for local troubleshooting inadvertently exposed JDWP to any host on the adjacent network.

Attack Vector

Exploitation requires network adjacency to the Keycloak host and a reachable debug port. The attacker connects a JDWP client such as jdb or a scripted debugger, requests class references, and invokes arbitrary methods to run code within the JVM. No credentials or user interaction are required.

# Patch excerpt from kc.sh removing the 0.0.0.0 default
 CLASSPATH_OPTS="'$(abs_path "../lib/quarkus-run.jar")'"

 DEBUG_MODE="${KC_DEBUG:-${DEBUG:-false}}"
-DEBUG_PORT="${KC_DEBUG_PORT:-${DEBUG_PORT:-8787}}"
+DEBUG_ADDRESS="${KC_DEBUG_PORT:-${DEBUG_PORT:-8787}}"
 DEBUG_SUSPEND="${KC_DEBUG_SUSPEND:-${DEBUG_SUSPEND:-n}}"
-DEBUG_ADDRESS="0.0.0.0:$DEBUG_PORT"

# Source: GitHub Keycloak commit 9e98f2b (PR #43574)

Detection Methods for CVE-2025-11538

Indicators of Compromise

• Keycloak JVM processes started with -agentlib:jdwp=transport=dt_socket,server=y,address=0.0.0.0:<port> in the command line
• Listening sockets on the default JDWP port 8787 bound to 0.0.0.0 on Keycloak hosts
• Inbound TCP connections to the JDWP port from hosts outside the administrator workstation range
• Unexpected child processes spawned by the Keycloak JVM, indicating debugger-driven code execution

Detection Strategies

• Inventory Keycloak startup arguments and environment variables (KC_DEBUG, DEBUG, KC_DEBUG_PORT) across all hosts to identify systems running in debug mode
• Run authenticated network scans against Keycloak subnets for open JDWP ports and validate the bind address using ss -tlnp or netstat -an
• Correlate process telemetry with network telemetry to flag any Keycloak JVM that both enables JDWP and accepts external connections

Monitoring Recommendations

• Alert on any new listener on TCP 8787 or custom debug ports on production identity infrastructure
• Monitor for JDWP handshake strings (JDWP-Handshake) in network traffic captures targeting Keycloak hosts
• Track configuration drift in kc.sh, kc.bat, and container entrypoints that reintroduce 0.0.0.0 bindings

How to Mitigate CVE-2025-11538

Immediate Actions Required

• Disable debug mode on all production Keycloak instances and remove the --debug flag from startup scripts, systemd units, and container manifests
• Apply upstream Keycloak updates containing commit 9e98f2b (PR #43574), which removes the 0.0.0.0 default
• Apply Red Hat updates from RHSA-2025:21370 and RHSA-2025:21371 for Red Hat Build of Keycloak and Single Sign-On deployments
• Block inbound access to the JDWP port at the host firewall and network perimeter until patches are deployed

Patch Information

The upstream fix is in GitHub Keycloak Pull Request #43574 and Keycloak commit 9e98f2b. It removes the hardcoded 0.0.0.0 bind and reads the debug address from KC_DEBUG_PORT or DEBUG_PORT, allowing operators to supply an explicit loopback address. Red Hat customers should install the fixed packages from RHSA-2025:21370 and RHSA-2025:21371. Additional vendor context is available in the Red Hat CVE page for CVE-2025-11538 and Red Hat Bug #2402622.

Workarounds

• If debug mode is required, set KC_DEBUG_PORT or DEBUG_PORT to 127.0.0.1:8787 so JDWP binds only to loopback
• Restrict access to the debug port with host firewall rules using iptables, nftables, or Windows Firewall to allow only administrator IP addresses
• Use SSH port forwarding to reach the debug interface remotely instead of exposing JDWP on the network
• Segment Keycloak servers on a management VLAN with strict ingress filtering to eliminate adjacent-network exposure

# Configuration example: bind JDWP to loopback and restrict with nftables
export KC_DEBUG=true
export KC_DEBUG_PORT=127.0.0.1:8787
./bin/kc.sh start

# Block external access to the debug port
nft add rule inet filter input tcp dport 8787 ip saddr != 127.0.0.1 drop