AIKIDO-2026-11174

TL;DR

Spring Kafka's retry topic infrastructure did not sufficiently validate user-controlled header values before acting on them. A producer could send a record with a crafted retry_topic-attempts header to supply an out-of-range attempt count and cause the retry topic router to misidentify where the message was in the retry sequence. Separately, the retry_topic_backoff-timestamp header was accepted without bounds checking, meaning a forged timestamp could instruct the backoff manager to impose an arbitrarily long pause, stalling the listener far beyond any intended retry window.