KingCide opened a new issue, #9633: URL: https://github.com/apache/rocketmq/issues/9633
### Before Creating the Bug Report - [x] I found a bug, not just asking a question, which should be created in [GitHub Discussions](https://github.com/apache/rocketmq/discussions). - [x] I have searched the [GitHub Issues](https://github.com/apache/rocketmq/issues) and [GitHub Discussions](https://github.com/apache/rocketmq/discussions) of this repository and believe that this is not a duplicate. - [x] I have confirmed that this bug belongs to the current repository, not other repositories of RocketMQ. ### Runtime platform environment MacOS 15.1 ### RocketMQ version 5.3.3 ### JDK Version 1.8 ### Describe the Bug - Under V1 retry topic naming (%RETRY%group_topic), different (topic, consumerGroup) pairs may map to the same retry topic name. When this happens, messages retried from one topic/group can be consumed by another topic/group that shares the same V1 retry topic name, causing cross-topic consumption and potential data leakage. #### Root cause - V1 retry topic naming (%RETRY%group_topic) loses information and is not one-to-one. Different combinations can collide, e.g., (Order_Topic, MyConsumerGroup) and (Topic, MyConsumerGroup_Order). - The broker routes retried messages based solely on the retry topic name, so collisions merge streams. ### Steps to Reproduce 1. Create two topic/group pairs: - Pair A: topic = Order_Topic, group = MyConsumerGroup - Pair B: topic = Topic, group = MyConsumerGroup_Order 2. Both pairs map to the same V1 retry topic: %RETRY%MyConsumerGroup_Order_Topic. 3. Use POP remoting push consumer. 4. Produce and consume messages on Order_Topic; do not ACK some messages so they enter %RETRY%MyConsumerGroup_Order_Topic. 5. Switch the consumer subscription to topic=Topic, group=MyConsumerGroup_Order (Pair B). 6. Observe that the consumer receives many retry messages from the shared V1 retry topic that actually originated from Order_Topic (Pair A). msg.getTopic() shows Topic, but the message body proves the origin was Order_Topic. ### What Did You Expect to See? Retry queues should be isolated per original (topic, group). A consumer on Pair B must not receive retry messages originating from Pair A. ### What Did You See Instead? Due to the non-injective V1 retry naming scheme, both pairs share the same retry topic name; consumers of one pair can receive retry messages from the other. Log Evidence: ``` [RETRY] Topic: Topic, QueueId: 0, ReconsumeTimes: 1, Content: Hello world, this is from Order_Topic timestamp: 2025-08-23 17:30:37,378 ... [RETRY] Topic: Topic, QueueId: 0, ReconsumeTimes: 1, Content: Hello world, this is from Order_Topic timestamp: 2025-08-23 17:30:37,378 ... ``` This demonstrates a critical message routing and security flaw. ### Additional Context #### Impact - Message correctness violation and potential data leakage across tenants or applications. - Hard-to-diagnose behavior because msg.getTopic() reflects the consumer’s current topic, masking the real source unless the payload carries explicit markers. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
