Bug 2291362 (CVE-2024-27309) - CVE-2024-27309 Kafka: Potential incorrect access control during migration from ZK mode to KRaft mode
Summary: CVE-2024-27309 Kafka: Potential incorrect access control during migration fro...
Status: NEW
Alias: CVE-2024-27309
Product: Security Response
Classification: Other
Component: vulnerability
Version: unspecified
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Product Security
QA Contact:
Depends On:
Blocks: 2291403
TreeView+ depends on / blocked
Reported: 2024-06-11 20:26 UTC by Marco Benatto
Modified: 2024-06-13 19:35 UTC (History)
4 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
A flaw was found in Apache Kafka during the migration from ZooKeeper (ZK) to KRaft mode that affects Access Control List (ACL) enforcement. Specifically, when an ACL is removed from a resource and the resource retains two or more other ACLs, Kafka may incorrectly treat the resource as having only one ACL. This issue can lead to misconfigured access permissions during the migration period. Depending on the type of ACLs (ALLOW or DENY) in use, the impact ranges from potential availability issues (for ALLOW ACLs) to confidentiality and integrity risks (for DENY ACLs). The bug can be mitigated by resetting broker states or adding new ACLs without causing metadata loss.
Clone Of:
Last Closed:

Attachments (Terms of Use)

Description Marco Benatto 2024-06-11 20:26:21 UTC
While an Apache Kafka cluster is being migrated from ZooKeeper mode to KRaft mode, in some cases ACLs will not be correctly enforced.

Two preconditions are needed to trigger the bug:
1. The administrator decides to remove an ACL
2. The resource associated with the removed ACL continues to have two or more other ACLs associated with it after the removal.

When those two preconditions are met, Kafka will treat the resource as if it had only one ACL associated with it after the removal, rather than the two or more that would be correct.

The incorrect condition is cleared by removing all brokers in ZK mode, or by adding a new ACL to the affected resource. Once the migration is completed, there is no metadata loss (the ACLs all remain).

The full impact depends on the ACLs in use. If only ALLOW ACLs were configured during the migration, the impact would be limited to availability impact. if DENY ACLs were configured, the impact could include confidentiality and integrity impact depending on the ACLs configured, as the DENY ACLs might be ignored due to this vulnerability during the migration period.


Note You need to log in before you can comment on or make changes to this bug.