CVE-2024-27309: Apache Kafka Auth Bypass Vulnerability

CVE-2024-27309 Overview

CVE-2024-27309 is an authorization flaw in Apache Kafka that occurs during cluster migration from ZooKeeper mode to KRaft mode. Access Control Lists (ACLs) are not correctly enforced when an administrator removes an ACL from a resource that still has two or more remaining ACLs. Kafka treats the resource as if only a single ACL applies, which can cause DENY ACLs to be ignored during the migration window. The vulnerability maps to [CWE-863: Incorrect Authorization] and affects clusters actively transitioning between metadata management modes.

Critical Impact
DENY ACLs may be silently bypassed during ZooKeeper-to-KRaft migration, enabling unauthorized read or write access to Kafka topics and resources.

Affected Products

Apache Kafka clusters undergoing migration from ZooKeeper mode to KRaft mode
Kafka deployments using multiple ACLs per resource
NetApp products bundling vulnerable Apache Kafka versions (per NTAP-20240705-0002)

Discovery Timeline

2024-04-12 - CVE-2024-27309 published to NVD
2025-06-10 - Last updated in NVD database

Technical Details for CVE-2024-27309

Vulnerability Analysis

Apache Kafka supports two metadata management modes: ZooKeeper and KRaft. During migration between these modes, the ACL enforcement subsystem mishandles resource-to-ACL mappings. When an administrator removes one ACL from a resource that still has two or more ACLs attached, Kafka incorrectly evaluates the resource as having only one ACL. This produces an authorization decision that ignores the remaining policy entries.

The practical effect depends on which ACL types are configured. ALLOW-only configurations experience availability impact, since legitimate access decisions may be inconsistent. Configurations using DENY ACLs face confidentiality and integrity impact, because deny rules can be skipped and previously blocked principals can read or modify topic data.

Root Cause

The root cause is incorrect authorization logic [CWE-863] in the dual-mode metadata layer that operates while brokers run in mixed ZooKeeper and KRaft states. The ACL cache or lookup path collapses multi-entry rule sets to a single entry after a removal operation, producing an incomplete authorization view.

Attack Vector

Exploitation requires the cluster to be mid-migration and an administrator to remove an ACL from a resource with two or more remaining ACLs. An attacker with network access to the Kafka cluster who is normally blocked by a DENY ACL can then access the affected resource over standard Kafka client protocols. The condition clears once all ZooKeeper-mode brokers are removed, a new ACL is added to the affected resource, or the migration completes.

No verified public exploit code or proof-of-concept is available for this issue. See the Apache mailing list announcement for the vendor description of the conditions required to trigger the bug.

Detection Methods for CVE-2024-27309

Indicators of Compromise

Successful Kafka client connections from principals that should be blocked by DENY ACLs during an active ZK-to-KRaft migration window
Audit log entries showing produce or consume operations on resources where the principal has an explicit DENY rule
Unexpected kafka-acls.sh removal events followed by access from previously denied identities

Detection Strategies

Correlate Kafka authorizer logs (kafka.authorizer.logger) with ACL change events to detect access decisions that contradict configured DENY rules
Inventory clusters in mixed ZooKeeper and KRaft state and flag any ACL removal operations performed during that window
Compare the effective ACL set returned by kafka-acls.sh --list against the configured policy baseline before and after each removal

Monitoring Recommendations

Forward Kafka broker authorizer and admin audit logs to a centralized SIEM with alerting on ACL mutation events
Track the kafka.controller:type=KafkaController,name=ZkMigrationState metric to know exactly when each cluster is in the vulnerable transition window
Alert on any principal performing operations on resources where its identity appears in a DENY entry

How to Mitigate CVE-2024-27309

Immediate Actions Required

Upgrade Apache Kafka to a fixed release before initiating any ZooKeeper-to-KRaft migration, per the Apache advisory
Avoid removing ACLs from resources that have two or more associated ACLs while the cluster is in mixed mode
Complete any in-progress migration as quickly as possible to exit the vulnerable state
Review authorizer logs for the migration period and validate that no DENY-protected resources were accessed by unauthorized principals

Patch Information

Apache published the fix in the project mailing list announcement. Refer to the official Apache Kafka advisory thread for fixed version details. NetApp customers should consult NTAP-20240705-0002 for product-specific guidance.

Workarounds

Clear the incorrect state by removing all brokers still running in ZooKeeper mode, which forces the cluster into pure KRaft operation
Add a new placeholder ACL to any affected resource to force re-evaluation of the full ACL set
Defer ACL removal operations until after the migration to KRaft is complete; ACL metadata is preserved across the transition

bash

# Verify cluster migration state and list ACLs on a resource before changes
kafka-metadata-quorum.sh --bootstrap-server broker:9092 describe --status
kafka-acls.sh --bootstrap-server broker:9092 --list --topic sensitive-topic

# After completing migration, re-validate that DENY ACLs are enforced
kafka-acls.sh --bootstrap-server broker:9092 --list --principal User:blocked-user