Kafka migration can temporarily enforce an incomplete ACL set

An access-control migration can preserve every stored rule and still enforce the wrong policy while it runs. Kafka's newly disclosed migration vulnerability has that shape. Removing one ACL can cause the resource's remaining rules to be represented incorrectly for enforcement, even though completing migration leaves the ACL metadata intact.

The Kafka security advisory for CVE-2024-27309, announced April 12, identifies a problem during ZooKeeper-to-KRaft migration. It recommends performing migrations that use ACLs on Kafka 3.6.2 or later. The affected releases are 3.5.0, 3.5.1, 3.5.2, 3.6.0 and 3.6.1.

Kafka's durable history changes how I think about the systems consuming it, but authorization still determines who can access that history. A migration that preserves the records while temporarily ignoring a denial can violate the system's intended permissions. Metadata correctness at the end is therefore insufficient evidence of correct enforcement throughout the transition.

Removal triggers the incomplete view

The original disclosure from Colin McCabe gives two prerequisites. An administrator removes an ACL during migration, and at least two ACLs remain associated with the affected resource after that removal. Kafka then treats the resource as having only one ACL instead of the surviving collection.

The number remaining after removal matters. Describing the trigger as any ACL update would be too broad. Adding an ACL has a different documented effect, and deleting the last rule does not match the stated condition of at least two surviving ACLs.

The resource association matters as well. Counting unrelated ACLs elsewhere in the cluster does not establish that the affected resource retains the required number of rules.

For an illustrative resource with three rules, deleting one should leave two rules available for evaluation. The defect instead presents a one-rule view. This arithmetic example follows the stated trigger without claiming which particular surviving rule the implementation will retain or omit.

The public disclosure does not identify the exact data structure or internal update operation responsible. It establishes the externally relevant mismatch between the surviving policy and its enforcement. A source-level explanation would need more evidence than the advisory provides, so the meaningful mechanism here is the resource-level collapse of multiple surviving rules into a single-rule view.

Missing permissions and missing denials have different effects

The advisory distinguishes installations using only ALLOW ACLs from those using DENY ACLs. With only allow rules, it limits the stated impact to availability. A legitimate operation can fail because the rule allowing it is no longer represented in the enforced view.

With deny rules, the impact can also include confidentiality and integrity. A denial that should constrain another permission can be omitted, and an operation that should be rejected can then succeed. The advisory makes that consequence conditional on the configured ACLs, rather than saying every affected cluster exposes every topic.

This distinction explains why reviewing only a successful authorized request would miss part of the defect. A policy has both intended acceptance and intended rejection behavior. Losing one member of its rule set can change either result, depending on the rule and the rest of the policy.

The failure does not require the administrator to intend a broader grant. Removing one rule can be a routine policy change with a clear expected surviving set. The security problem is that enforcement no longer reflects that set during the affected migration state.

Stored metadata and effective policy can disagree

Apache explicitly says the migration does not lose the ACL metadata. Once migration completes, the ACLs remain. That narrows the defect to the policy being applied during the transition rather than permanent deletion of the surviving records.

The incorrect condition clears when all brokers in ZooKeeper mode have been removed. The advisory also says adding a new ACL to the affected resource clears it. These are documented state changes that restore the correct condition, not evidence that the preceding interval was harmless.

This matters for the meaning of a post-migration audit. Finding the expected ACLs afterward would confirm that metadata survived. It would not show that every request during migration was evaluated against the expected policy. The two observations concern different times and different properties.

My preference is to keep both properties explicit in migration requirements. Preserving the rule set is necessary, and applying it correctly while metadata management changes is also necessary. An end-state comparison cannot replace evidence about enforcement while the cluster runs in the intermediate configuration.

The migration interval is part of the supported behavior

The vulnerability illustrates why mixed-mode operation needs its own security assessment. Migrating cluster metadata introduces a period in which components operating under different modes must agree on current authorization state. A completed KRaft cluster can be correct while a transition to it has an incorrect response to one update pattern.

Apache's remediation advice is to use 3.6.2 or later for migrations involving ACLs. That is more useful than treating successful completion as the primary remedy. Completing the transition can clear the condition, but it does not retroactively correct permissions applied before completion.

The identified update pattern also suggests a concrete verification case. Begin with enough ACLs that removal leaves at least two, remove one while the cluster is in the migration interval, and check the decisions governed by each surviving rule. Both allowed and denied operations need their expected outcomes preserved.

That case should include a resource with a deny rule when the intended policy uses one. Testing only a resource with one surviving permission would not meet the advisory's trigger. Likewise, comparing the final ACL listing would verify persistence without necessarily exposing the temporary enforcement failure.

The April disclosure is therefore precise about a limited but consequential state. Particular ACL removals during migration can leave enforcement using an incomplete view, with effects determined by the rules omitted. The fix version, trigger conditions and separate outcomes for allow and deny policies identify what an operator needs to understand before moving an ACL-protected cluster between metadata systems.