Cloudanix VulnDB

CVE-2024-27309

High · 7.4

CVSS

7.4

EPSS

1.1%

Published

Apr 12, 2024

CISA due date

—

Cloudanix analysis

Monitor only SSVC: Track

While moving access controls between two systems, deleting one rule can temporarily let some blocked users through until the move finishes.

Exploitation
Remote Unauthenticated
Attacker needs
None
Complexity
High
Impact
Full Compromise
Component
Application
Class
Authorization Bypass
Remediation
Upgrade
Effort
Medium
Patch risk
Low

What it actually does

During ZooKeeper to KRaft migration, removing an ACL from a resource that retains two or more ACLs causes the broker to incorrectly evaluate the resource as having only a single ACL, resulting in DENY rules being ignored while ALLOW rules remain enforced.

Why it matters to the business

Organizations performing the migration face temporary exposure to unauthorized access or service disruption if DENY ACLs are bypassed, with urgency low given no known exploitation and stable EPSS.

How an attack unfolds

An attacker waits for an administrator to remove an ACL on a multi-ACL resource during the migration window; the resulting mis-evaluation allows requests that should be denied by remaining DENY rules to succeed until migration completes or a corrective ACL is added.

How to fix it

Complete the migration by removing all ZooKeeper-mode brokers or add a new ACL to affected resources; upgrade affected installations to the versions that resolve the ACL evaluation logic.

How to confirm the fix worked

After upgrade or migration completion, verify that resources with multiple ACLs correctly enforce all rules by testing both ALLOW and DENY combinations and confirming no residual single-ACL mis-evaluation state exists.

Typical attack path

  1. Confirm target cluster is actively migrating from ZooKeeper to KRaft mode
  2. Identify resources whose ACL count will drop to two or more after a planned removal
  3. Trigger or observe the ACL removal operation
  4. Issue requests that a DENY ACL would normally block

How to detect it

Review Kafka authorizer and controller logs during the migration window for ACL removal events on resources that still hold multiple ACLs; correlate with unexpected access attempts that DENY rules should have blocked.

What your security team should do

  • Prioritize completing KRaft migration or adding compensating ACLs on any cluster still in the mixed-mode window
  • Audit ACL configurations for reliance on DENY rules before starting migration
  • Monitor Kafka broker logs for ACL update events during the migration period

The record

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.

Affected packages

Ecosystem Package Introduced Fixed
Maven org.apache.kafka:kafka-metadata 3.5.0 3.6.2
Bitnami kafka 3.5.0 3.5.2
Chainguard kafka-jre-bcfips 0 3.7.0-r0
Ubuntu:Pro:18.04:LTS kafka 0 No fix
maven org.apache.kafka/kafka-metadata 3.5.0 3.6.2

Related vulnerabilities