Hi Mike, Thanks for the write-up — the observation is accurate: the consumer- and share-group describe handlers filter only the assignment topics for DESCRIBE, not subscribedTopicNames/subscribedTopicRegex. Feel free to file a JIRA so we can track and discuss it (or I can).
That said, I'm not yet convinced anything needs to change — the current behavior may well be fine. In the end, the API just echoes back the parameters the members sent in their heartbeats, so it's not clear the describe path should filter them at all. Blanking the whole group like we do for assignment topics may be too heavy-handed, and subscribedTopicRegex is a member-chosen pattern with no clean way to authorize it. So it's worth agreeing on what the response should return before deciding to patch anything. Curious what others think, and thanks again. -David On Mon, Aug 17, 2026 at 11:05 AM Mike Read <[email protected]> wrote: > > 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>
