CVE-2024-27309
Apache Kafka: Potential incorrect access control during migration from ZK mode to KRaft mode
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:
- The administrator decides to remove an ACL
- 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.
Attack profile
How easy it is to exploit
- Attack vector
- Network
- Complexity
- High
- Privileges needed
- None
- User interaction
- None
What an attacker can affect
- Confidentiality
- High
- Integrity
- High
- Availability
- None
Exploit likelihood
What each source reports
CVE List Score used
Apache Kafka: Potential incorrect access control during migration from ZK mode to KRaft mode
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:
- The administrator decides to remove an ACL
- 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.
- Record
CVE-2024-27309- CVSS 3.1
- 7.4 High
CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:N - Weakness
- CWE-863
- Updated
- 2026-11-02
EUVDEUVD-2024-1140
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:
- The administrator decides to remove an ACL
- 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.
- Record
EUVD-2024-1140- CVSS 3.1
- 7.4 High
CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:N - Updated
- 2026-11-02
GitHub AdvisoriesGHSA-79vv-vp32-gpp7
Apache Kafka: Potential incorrect access control during migration from ZK mode to KRaft mode
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:
- The administrator decides to remove an ACL
- 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.
- Record
GHSA-79vv-vp32-gpp7- CVSS 4.0
- 7.6 High
CVSS:4.0/AV:N/AC:H/AT:N/PR:L/UI:N/VC:H/VI:H/VA:N/SC:N/SI:N/SA:N - CVSS 3.1
- 6.8 Medium
CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:N - Weakness
- CWE-863
- Updated
- 2026-11-02
NVD
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:
- The administrator decides to remove an ACL
- 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.
- Record
CVE-2024-27309- CVSS 3.1
- 7.4 High
CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:N - Weakness
- CWE-863
- Updated
- 2026-11-02
OSV
Apache Kafka: Potential incorrect access control during migration from ZK mode to KRaft mode
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:
- The administrator decides to remove an ACL
- 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.
- Record
CVE-2024-27309- CVSS 3.1
- 7.4 High
CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:N - Weakness
- CWE-863
- Updated
- 2026-11-02
OSVGHSA-79vv-vp32-gpp7
Apache Kafka: Potential incorrect access control during migration from ZK mode to KRaft mode
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:
- The administrator decides to remove an ACL
- 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.
- Record
GHSA-79vv-vp32-gpp7- CVSS 4.0
- 7.6 High
CVSS:4.0/AV:N/AC:H/AT:N/PR:L/UI:N/VC:H/VI:H/VA:N/SC:N/SI:N/SA:N - CVSS 3.1
- 6.8 Medium
CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:N - Weakness
- CWE-863
- Updated
- 2026-11-02
OSVUBUNTU-CVE-2024-27309
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.
- Record
UBUNTU-CVE-2024-27309- CVSS 3.1
- 7.4 High
CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:N - Updated
- 2026-11-02
OSVBIT-kafka-2024-27309 No score
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 ACL2. 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.
- Record
BIT-kafka-2024-27309- Updated
- 2026-11-02
OSVROOT-APP-MAVEN-CVE-2024-27309 No score
CVE-2024-27309 in io.root.org.apache.kafka:kafka-metadata - Patched by Root
Root has patched CVE-2024-27309 in the io.root.org.apache.kafka:kafka-metadata package for Root:Maven. Multiple fixed versions available.
- Record
ROOT-APP-MAVEN-CVE-2024-27309- Updated
- 2026-11-02
Affected products
Affected packages
| Package | Affected | Fixed |
|---|---|---|
org.apache.kafka:kafka-metadataMaven |
3.5.0 up to 3.6.2 | 3.6.2 |
kafkaBitnami |
3.5.0 up to 3.5.2, 3.6.0 up to 3.6.2 | 3.5.23.6.2 |
org.apache.kafka:kafka-metadataMaven |
3.5.0 up to 3.6.2, plus listed versions 3.5.13.5.23.6.03.6.1 |
3.6.2 |
io.root.org.apache.kafka:kafka-metadataRoot:Maven |
before 3.6.0-root.io.2 | 3.6.0-root.io.23.6.0-root.io.3 |
org.apache.kafka:kafka-metadataRoot:Maven |
before 3.6.0-aikido.3 | 3.6.0-aikido.3 |
kafkaUbuntu:Pro:18.04:LTS |
All versions, plus listed versions 2.2.0u2-0ubuntu3.12.2.0u2-0ubuntu3.22.2.2u1-0ubuntu1+esm2 |
None known |
History
| Recorded | Changed | Sources |
|---|---|---|
| first indexed | CVE List, EUVD, GitHub Advisories, NVD, OSV |
Dates are when Every CVE recorded each change. Upstream dates may differ.
In short
CVE-2024-27309 is a high vulnerability (CVSS 7.4) in Apache Kafka, published April 12, 2024. No source lists public exploit code. EPSS puts the chance of exploitation in the next 30 days at 1.12%, the 66th percentile. Fixed in org.apache.kafka:kafka-metadata 3.6.2.