Hi Kafka developers, While reading the group-describe handlers I noticed a small consistency gap in the topic-authorization filtering that I wanted to flag. To be clear up front: this is NOT a security vulnerability — I could not turn it into a real information leak, and I am deliberately sending it here (dev list) rather than to the security list. It is a defense-in-depth / code-consistency suggestion; happy to open a JIRA + PR if it seems worthwhile.
Observation (against current trunk): - handleConsumerGroupDescribe (core .../KafkaApis.scala, ~2762-2790) builds the set of topics it authorizes for DESCRIBE only from each member's assignment / targetAssignment topic-partitions. It then blanks the whole group (TOPIC_AUTHORIZATION_FAILED) if any ASSIGNED topic is unauthorized. - However, the response also carries Member.SubscribedTopicNames and SubscribedTopicRegex (populated at ConsumerGroupMember, ~504-505), and those two fields are never run through the same DESCRIBE-TOPIC filter. - handleShareGroupDescribe (~3236-3261) has the identical shape via ShareGroupMember. Why it is not a security issue today: the assignment-union filter is group-wide, so as soon as a subscribed topic actually exists it appears in some member's assignment and the whole group is blanked — so a caller with GROUP DESCRIBE but without TOPIC DESCRIBE only ever sees subscribed *names* for topics that are not assigned anywhere in the group (deleted / never-created / a regex that matches nothing / a brand-new subscription in the pre-assignment window). That is subscription *intent*, not topic existence, offsets, config, or data — and the classic handleDescribeGroupsRequest exposes subscription metadata to any GROUP-DESCRIBE holder anyway, so there is no regression. A subscribed regex is also a subscriber-chosen pattern, not an ACL resource. Suggestion (consistency, not a fix for an exploit): run member.subscribedTopicNames (and the names implied by subscribedTopicRegex) through the same DESCRIBE-TOPIC authorization + per-group hasUnauthorizedTopic predicate that the assignment topics already use, in both the consumer-group and share-group describe handlers. That would make the handlers' behavior match their own apparent intent (they clearly try to hide unauthorized topics), and would be robust against future changes to the group-blanking backstop. If you agree it is worth tidying up, I am glad to file it and send a patch. Thanks for all your work on Kafka. -- Respectfully, *Mike Read* [email protected] github.com/Michael-JRead <https://www.google.com/url?q=http://github.com/Michael-JRead&source=gmail&ust=1785788327468000&sa=E> My Offensive Security Portfolio <https://www.mikeread.us/offensive-security>
