Apache Kafka Security: Known CVEs and What They Mean for EOL Versions

Kafka's Security Architecture

Apache Kafka's security model has evolved substantially across major versions. The authentication layer (SASL/PLAIN, SASL/SCRAM, mTLS), the authorization layer (ACLs), and the inter-broker and broker-to-ZooKeeper communication channels each carry independent CVE histories. Understanding which component is affected by a specific CVE is a prerequisite for accurate risk assessment.

For organisations running Kafka 2.x or early 3.x releases, many of the security improvements introduced in 3.x — including KRaft mode (ZooKeeper elimination), improved SASL handling, and the Authorization API changes — are not available without an upgrade. Running EOL versions means living without both upstream CVE patches and the security architecture improvements introduced in supported versions.

The ZooKeeper Attack Surface

Kafka clusters using ZooKeeper for coordination (Kafka 2.x and early 3.x in non-KRaft mode) carry a compounded attack surface: both the Kafka brokers and the ZooKeeper ensemble must be patched independently. ZooKeeper has its own CVE cadence, and ZooKeeper 3.6 and 3.7 — which are widely deployed alongside Kafka 2.x — have accumulated advisories in the authentication and network handling subsystems. In the EOL ZooKeeper-mode Kafka deployment, both components require extended lifecycle attention.

Key CVE Categories in Kafka

• SASL/PLAIN credential handling: Several advisories have addressed credential exposure or bypass in SASL/PLAIN and SASL/SCRAM implementations across Kafka 2.x versions. These are the most operationally critical because they affect authentication directly.
• Admin API authorization bypass: The Kafka Admin API, which can create topics, modify ACLs, and alter cluster configurations, has been the subject of authorization bypass advisories that allow under-privileged clients to perform privileged operations in specific configurations.
• Log directory traversal: Advisory in the log dir management API allowed path traversal under certain controller configurations — relevant primarily to multi-tenant Kafka deployments.
• Deserialization vulnerabilities in connectors: Kafka Connect's plugin loading mechanism has historically been susceptible to unsafe deserialization, particularly when untrusted connector plugins are loaded.

The KRaft Migration as a Security Improvement

Migrating from ZooKeeper mode to KRaft mode (available as production-ready from Kafka 3.3+) eliminates the ZooKeeper attack surface entirely. KRaft consolidates metadata management into the Kafka cluster itself, using the Raft consensus algorithm rather than an external ensemble. Beyond the operational simplification, this removes an entire category of cross-component CVE exposure.

For teams on EOL Kafka 2.x or 3.0–3.4 in ZooKeeper mode, the migration to KRaft-mode 3.7+ or 3.8+ is both a security improvement and a lifecycle compliance action — a double win that justifies prioritising the upgrade in planning cycles.

OSSeva Kafka Coverage

OSSeva maintains CVE patches for Kafka 2.8 through 3.5. Coverage includes both the Kafka broker and the Kafka Connect runtime. Patches are backported individually against the target minor version and tested against common client library versions (kafka-clients 2.x and 3.x) to confirm compatibility.

Conclusion

Kafka's security exposure in EOL versions is real but manageable with the right controls. Network isolation reduces the exploitability of most CVEs; extended lifecycle patching closes the compliance gap; and a planned migration to current KRaft-mode Kafka eliminates the ZooKeeper attack surface permanently. The worst posture is unchanged EOL Kafka with an indefinite upgrade timeline and no compensating controls documented for auditors.