Authorization Flaw in org.apache.kafka:kafka-metadata (CVE-2024-27309)
Summary
Vulnerability in org.apache.kafka:kafka-metadata (CVE-2024-27309). Confidential information can be exposed externally. Mitigation: upgrade to 3.6.2 or later.
Original description
The description as published by the source.
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.
Source: OSV.dev (Open Source Vulnerabilities) NVD GitHub Advisory OSV
Auto-generated summary
Assembled by SecPulse from the source data (CVSS, CWE, affected versions) using templates — no AI involved. Check the original description and references below for exact details.
A vulnerability tracked as CVE-2024-27309 has been found in org.apache.kafka:kafka-metadata.
Confidential information can be exposed externally.
What to do: upgrade org.apache.kafka:kafka-metadata to 3.6.2 or later.
If unsure, ask your IT team or search "org.apache.kafka:kafka-metadata CVE-2024-27309" on the vendor's site.
CVE-2024-27309 (org.apache.kafka:kafka-metadata) — CWE-863
Attack vector: remote (network-reachable) / no user interaction
Patched: 3.6.2 — apply immediately
Plan: 1) Audit SBOM/dependencies, 2) Stage→prod upgrade, 3) Add WAF/proxy monitoring on affected endpoints, 4) Hunt IOCs in logs.
Refs: see the GHSA / vendor advisory / patched release linked on this page.
Incorrect authorization (CWE-863) exists in org.apache.kafka:kafka-metadata.
Check the vendor advisory for the affected versions of org.apache.kafka:kafka-metadata.
Severity: ?. Confidential information can be exposed externally.
Update to 3.6.2.
Until the patch is applied: disable the affected feature, apply WAF rules, or restrict access via network ACLs.
Search webserver/proxy logs for unusual request patterns matching this CVE's known IOCs. Audit SBOM/dependencies to find affected services.
Response actions
Concrete steps and command examples for SOC/SRE teams to execute in order
-
1Identify exposure identify
Audit SBOM/dependencies for affected components.資産台帳・SBOM・依存マニフェストで org.apache.kafka:kafka-metadata を使っているサービスとバージョンを洗い出す。
-
2Apply patch patch
Upgrade org.apache.kafka:kafka-metadata to 3.6.2ステージング環境で 3.6.2 に上げて回帰テスト → 本番反映。回帰テストはアプリの主要ハッピーパスを含めること。
-
3Post-deployment verification verify
Confirm patched version is live in productionパッチ適用後、ステージングで PoC または同等の悪用パターンを再現して脆弱性が閉じたことを確認。本番ではアクセスログ・WAF でアラート再発が無いか継続監視。
Affected packages
References
- advisory nvd.nist.gov
- advisory lists.apache.org
- advisory github.com
- advisory security.netapp.com
- package github.com
- web github.com
- web security.netapp.com
- web openwall.com