Skip to main content
CVE Vulnerability Database
Vulnerability Database/CVE-2024-32030

CVE-2024-32030: Kafka UI RCE Vulnerability

CVE-2024-32030 is a remote code execution flaw in Kafka UI that exploits JMX deserialization when connecting to malicious brokers. This article covers the technical details, affected configurations, security impact, and mitigation.

Updated:

CVE-2024-32030 Overview

CVE-2024-32030 is a high-severity insecure deserialization vulnerability in Kafka UI, an open-source web interface for managing Apache Kafka clusters. The flaw resides in the Java Management Extensions (JMX) monitoring feature, which relies on the Remote Method Invocation (RMI) protocol. An attacker who can influence the broker connection target can stand up a malicious RMI listener that returns a crafted serialized object. Kafka UI ships with gadget chains on its classpath, enabling remote code execution on the Kafka UI backend. The issue is tracked as GHSL-2023-230 and was reported by the GitHub Security Lab.

Critical Impact

Post-authentication remote code execution on the Kafka UI host. Kafka UI does not enable authentication by default, raising the practical impact to unauthenticated RCE in common deployments.

Affected Products

  • Provectus Kafka UI versions prior to 0.7.2
  • Deployments with dynamic.config.enabled set to true
  • Deployments where an attacker has access to a connected Kafka cluster

Discovery Timeline

  • Vulnerability discovered and reported by the GitHub Security Lab (tracked as GHSL-2023-230)
  • 2024-06-19 - CVE-2024-32030 published to NVD
  • 2026-04-15 - Last updated in NVD database

Technical Details for CVE-2024-32030

Vulnerability Analysis

Kafka UI exposes an API that lets users connect the backend to arbitrary Kafka brokers by specifying network address and port. A separate feature connects to a broker's JMX port to gather performance metrics. JMX communication is layered on the RMI protocol, which performs Java object deserialization on returned values. The Kafka UI classpath contains libraries that ship with known deserialization gadget chains, including commons-collections. This combination allows an attacker-controlled RMI endpoint to drive the deserialization process toward arbitrary code execution inside the Kafka UI JVM. The vulnerability is classified under CWE-94: Improper Control of Generation of Code.

Root Cause

The root cause is unsafe deserialization of remote objects returned during JMX/RMI calls combined with the presence of exploitable gadget chains on the classpath. Kafka UI does not validate or restrict the destination of JMX connections, and it does not constrain the types accepted during deserialization. Authentication is not enabled by default, removing a key barrier to exploitation.

Attack Vector

Two deployment configurations expose the flaw. First, when dynamic.config.enabled is set, which the project's own README.md recommends, any user reaching the UI can register a new broker pointing to an attacker-controlled host. Second, an attacker who already has access to a legitimate Kafka cluster connected to Kafka UI can pivot by exposing a malicious JMX endpoint. The attacker runs an RMI listener that returns a malicious serialized object for any RMI call, triggering gadget chain execution.

java
// Patch excerpt: kafka-ui-api Permission.java
 import lombok.EqualsAndHashCode;
 import lombok.Getter;
 import lombok.ToString;
-import org.apache.commons.collections.CollectionUtils;
+import org.apache.commons.collections4.CollectionUtils;
 import org.springframework.util.Assert;

 @Getter

Source: GitHub commit 83b5a60

The fix migrates from commons-collections to commons-collections4 and excludes the legacy library from transitive dependencies in kafka-ui-api/pom.xml, removing the most common Java deserialization gadget chain from the classpath.

Detection Methods for CVE-2024-32030

Indicators of Compromise

  • Outbound RMI/JMX connections from the Kafka UI host to unexpected external IP addresses or ports.
  • Child processes spawned by the Kafka UI Java process (for example, /bin/sh, bash, curl, wget, python).
  • New or modified broker entries in Kafka UI configuration referencing untrusted hosts.
  • Unexpected DNS lookups initiated by the Kafka UI JVM during JMX connection attempts.

Detection Strategies

  • Inspect Kafka UI logs for JMX connection attempts to unrecognized broker endpoints.
  • Monitor the Kafka UI JVM for deserialization of commons-collections classes, which indicates legacy library presence and potential gadget invocation.
  • Hunt for process lineage where the Kafka UI Java process is the parent of shell or scripting interpreters.
  • Alert on configuration changes that toggle dynamic.config.enabled or add new cluster entries.

Monitoring Recommendations

  • Restrict and log egress traffic from Kafka UI hosts, alerting on connections to ports outside the approved broker list.
  • Capture and retain JVM audit logs covering class loading and RMI registry activity.
  • Track Kafka UI version inventory across environments and flag any deployments below 0.7.2.

How to Mitigate CVE-2024-32030

Immediate Actions Required

  • Upgrade Kafka UI to version 0.7.2 or later on every deployment.
  • Disable dynamic.config.enabled unless absolutely required for operations.
  • Enable authentication on Kafka UI and place the interface behind a network boundary that blocks untrusted clients.
  • Audit existing broker configurations and remove any entries pointing to hosts outside the approved cluster inventory.

Patch Information

The maintainers addressed the issue in Kafka UI version 0.7.2 via pull request #4427 and commit 83b5a60. The patch removes the legacy commons-collections dependency that supplied the primary deserialization gadget chain. See the GitHub Security Lab advisory for full technical details.

Workarounds

  • No official workarounds exist. The vendor states all users must upgrade.
  • As a compensating control, restrict outbound network access from the Kafka UI host to only known broker IP addresses and JMX ports.
  • Run Kafka UI as a low-privilege user in an isolated container to limit blast radius if exploitation succeeds.
bash
# Example egress restriction with iptables, allowing only approved broker hosts
iptables -A OUTPUT -d 10.0.10.11 -p tcp --dport 9999 -j ACCEPT
iptables -A OUTPUT -d 10.0.10.12 -p tcp --dport 9999 -j ACCEPT
iptables -A OUTPUT -p tcp --dport 1024:65535 -j REJECT

Disclaimer: This content was generated using AI. While we strive for accuracy, please verify critical information with official sources.

Default Legacy - Prefooter | Experience the World’s Most Advanced Cybersecurity Platform

Experience the Most Advanced Cybersecurity Platform

See how the world’s most intelligent, autonomous cybersecurity platform can protect your organization today and into the future.