Skip to main content
CVE Vulnerability Database
Vulnerability Database/CVE-2026-41115

CVE-2026-41115: Apache Kafka Auth Bypass Vulnerability

CVE-2026-41115 is an authorization bypass flaw in Apache Kafka affecting CONSUMER_GROUP_DESCRIBE API permissions. This discrepancy can lead to misconfigured ACLs and unintended access. This article covers technical details, affected versions, security impact, and mitigation strategies.

Published:

CVE-2026-41115 Overview

CVE-2026-41115 is an improper authorization vulnerability in Apache Kafka affecting the CONSUMER_GROUP_DESCRIBE (API key 69) handler. The implementation validates the DESCRIBE operation on the GROUP resource, while the official Kafka documentation and KIP-848 state that the READ operation is required. This discrepancy between documentation and code leads administrators to configure Access Control Lists (ACLs) that do not enforce the intended privilege boundaries. Operators relying on the documented behavior can inadvertently grant READ permission to users who should not be able to join or sync consumer groups, or expose group metadata to principals holding only DESCRIBE permission.

Critical Impact

Misconfigured Kafka ACLs can leak consumer group metadata to low-privileged principals and grant unintended group membership rights.

Affected Products

  • Apache Kafka (versions implementing the CONSUMER_GROUP_DESCRIBE API per KIP-848)
  • Brokers exposing the new consumer group protocol via the network
  • Deployments that authored ACLs based on the published KIP-848 / Kafka documentation

Discovery Timeline

  • 2026-06-02 - CVE-2026-41115 published to the National Vulnerability Database (NVD)
  • 2026-06-02 - Disclosure posted to the Openwall oss-security mailing list
  • 2026-06-03 - Last updated in NVD database

Technical Details for CVE-2026-41115

Vulnerability Analysis

The flaw is a documentation-versus-implementation mismatch classified under [CWE-285] Improper Authorization. The CONSUMER_GROUP_DESCRIBE API was introduced as part of KIP-848 to support the next-generation consumer group protocol. The Kafka project has clarified that the intended and correct permission for this API is DESCRIBE on the GROUP resource, which matches what the broker actually checks. However, Kafka's published documentation and the KIP-848 design document state that READ is required. Administrators who follow the documentation will provision READ GROUP ACLs for clients that need to query group state. Because the broker only requires DESCRIBE GROUP, those clients receive broader rights than necessary, and other principals that already hold DESCRIBE GROUP can also retrieve sensitive group metadata such as member assignments, generation IDs, and subscribed topics.

Root Cause

The root cause is inconsistent authorization specification between Kafka's documentation and its broker code. The broker enforces DESCRIBE on the GROUP resource for CONSUMER_GROUP_DESCRIBE, but the documentation prescribes READ. ACLs derived from the documentation therefore over-provision READ GROUP, which also implicitly authorizes join and sync operations against the consumer group.

Attack Vector

Exploitation requires network access to a Kafka broker and valid credentials for a principal that holds DESCRIBE GROUP on the targeted consumer group. The attacker issues a CONSUMER_GROUP_DESCRIBE request and receives consumer group metadata that the operator believed was gated behind READ GROUP. No user interaction is required, and the attack does not affect integrity or availability of the broker. A separate misconfiguration risk arises when administrators grant READ GROUP based on the documentation, unintentionally permitting those principals to join and sync the group.

No public proof-of-concept exploit is available, and the vulnerability is not listed in the CISA Known Exploited Vulnerabilities catalog.

Detection Methods for CVE-2026-41115

Indicators of Compromise

  • Unexpected CONSUMER_GROUP_DESCRIBE (API key 69) requests from principals not associated with consumer applications.
  • Successful group metadata retrieval by users holding only DESCRIBE GROUP ACLs.
  • Principals issuing JoinGroup or SyncGroup calls after receiving overly permissive READ GROUP ACLs.

Detection Strategies

  • Audit Kafka authorizer logs for Operation = Describe events on Group resources tied to API key 69 and correlate with principal identities.
  • Compare configured ACLs against an inventory of legitimate consumer applications to surface principals with DESCRIBE GROUP that should not see group state.
  • Review changes to ACLs added after KIP-848 adoption for READ GROUP grants that exceed least privilege.

Monitoring Recommendations

  • Enable Kafka authorizer logging at INFO or DEBUG for ACL decisions and ship logs to a centralized analytics platform.
  • Alert on new principals invoking CONSUMER_GROUP_DESCRIBE against sensitive consumer groups such as those backing financial or PII pipelines.
  • Track baseline counts of group-describe operations per principal and alert on statistical deviations.

How to Mitigate CVE-2026-41115

Immediate Actions Required

  • Inventory all consumer group ACLs and identify principals granted READ on GROUP resources solely to call CONSUMER_GROUP_DESCRIBE.
  • Replace unnecessary READ GROUP grants with DESCRIBE GROUP to restore least privilege, since DESCRIBE is the permission the broker actually enforces.
  • Review which principals currently hold DESCRIBE GROUP and revoke access where consumer group metadata exposure is not acceptable.

Patch Information

The Apache Kafka project has stated that the broker implementation is correct and that the Kafka documentation and KIP-848 will be updated to specify DESCRIBE GROUP as the required permission for CONSUMER_GROUP_DESCRIBE. No code patch is required. Refer to the Apache Kafka CVE List and the Openwall OSS-Security Post for the authoritative advisory.

Workarounds

  • Rebuild ACL policies using DESCRIBE GROUP as the canonical permission for clients that only need to query group state.
  • Restrict READ GROUP ACLs exclusively to consumer applications that legitimately join and sync the group.
  • Segment sensitive consumer groups behind dedicated principals and rotate credentials for any principal previously over-provisioned with READ GROUP.

Disclaimer: This content was generated using AI. While we strive for accuracy, please verify critical information with official sources.

Default Legacy - Prefooter | Experience the World’s Most Advanced Cybersecurity Platform

Experience the Most Advanced Cybersecurity Platform

See how the world’s most intelligent, autonomous cybersecurity platform can protect your organization today and into the future.