Apache Kafka EUVD-2026-33904

Exploitation requires: (1) network access to the Kafka broker with a valid authenticated account (PR:L per CVSS vector - unauthenticated access is not possible); (2) the target Kafka deployment must be running version 4.0.0 through 4.3.0, which introduced the KIP-848 consumer group protocol; (3) ACLs must have been configured following the (incorrect) official documentation that specified READ as the required operation - deployments where ACLs were never set or were set permissively are not distinctly affected. The limiting factors are the authenticated access requirement and the narrow 4.x version band. Kafka deployments on the 3.x line or those with no group-level ACL enforcement (using allow.everyone.if.no.acl.found=true) are not affected by this authorization discrepancy in a meaningful way.

The CVSS 3.1 base score of 4.3 (AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N) reflects a low-severity, network-accessible information disclosure requiring authenticated access (PR:L). EPSS at 0.02% in the 4th percentile strongly suggests this vulnerability is not being actively exploited in the wild and is unlikely to attract automated scanning. There is no KEV listing and no known POC. The vendor's own advisory clarifies that the code behavior is actually correct and the documentation is wrong - meaning this is primarily an ACL misconfiguration risk for operators who followed incorrect documentation rather than a traditional exploitable flaw. Real-world risk is concentrated in Kafka deployments where ACLs were constructed strictly per KIP-848 documentation: those environments may have unintentional READ grants or unintended DESCRIBE-based access to consumer group metadata. The integrity and availability impact are both None, limiting blast radius to confidentiality of group metadata. This is a low operational priority absent evidence of internal ACL misconfiguration.

An authenticated Kafka user with only DESCRIBE permission on a GROUP resource - an access level typically considered read-only metadata inspection - can invoke the CONSUMER_GROUP_DESCRIBE API and retrieve sensitive consumer group state such as member assignments, offsets, and group coordinator details, which the operator intended to restrict to READ-privileged principals. Alternatively, an operator who followed the original KIP-848 documentation may have granted READ on GROUP to principals needing group describe access, inadvertently allowing those principals to join or sync consumer groups. No public exploit code is identified at time of analysis, and exploitation requires valid authenticated credentials.