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

# 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