Skip to content
Fencer Vulns
high 7.4

CVE-2024-27309 json

Apache Kafka: Potential incorrect access control during migration from ZK mode to KRaft mode

published 2024-04-12 2 y ago modified 2026-08-07 3 mo ago also BIT-kafka-2024-27309 , EUVD-2024-1140 , GHSA-79vv-vp32-gpp7

cvss
7.4
version 3.1, CNA
cisa kev
Not listed
not in CISA's catalog
epss
1.1%
EPSS 1.1% chance of exploitation in 30 days, percentile 66%
public exploits
0
none known

Summary

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.

Patch / fix

  • maven org.apache.kafka:kafka-metadata 3.6.2
  • bitnami kafka 3.5.2, 3.6.2
  • org.apache.kafka kafka-metadata 3.6.2

Vendor advisories

What the vendors themselves say about their products: affected, fixed or not affected, and what to do.

red hat product security vex CVE-2024-27309 updated cvss 6.8

Kafka: Potential incorrect access control during migration from ZK mode to KRaft mode

  • Red Hat streams for Apache Kafka kafka
    affected: workaround, no fix planned “Will not fix”

Red Hat CSAF VEX © Red Hat, Inc., from https://security.access.redhat.com/data/csaf/v2/vex/; changed: reduced to product statuses and remediations. CC BY 4.0 · csaf

CISA SSVC

Exploitation
none
Automatable
no
Technical impact
total
Assessed
15 mo ago

Exploit prediction

1.13% chance of exploitation in the next 30 days, higher than 66% of all scored CVEs (FIRST EPSS, 2026-11-08).

CVSS scores

assigned by version score vector
CISA ADP 3.1 7.4 CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:N
GitHub 3.1 6.8 CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:N
CNA 3.1 7.4 CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:N

Affected packages

ecosystem package affected fixed in
maven org.apache.kafka:kafka-metadata
>=3.5.0, <3.6.2
3.6.2
bitnami kafka
>=3.5.0, <3.5.2
>=3.6.0, <3.6.2
3.5.2
3.6.2

Affected products

  • Apache Software Foundation Apache Kafka
  • apache kafka

Classification

Weakness

References

Sources

Fencer Vulns keeps one entry per vulnerability: the CVE id wins, then GHSA, and records that alias each other are merged, except that two CVEs always keep separate entries. The same data is available as JSON.

CPEs and fixed versions use Anchore's correction of NVD's data: Added CPE configurations because not yet analyzed by NVD.