Spring Kafka CVE-2026-41727

Exploitation requires three concrete conditions to be simultaneously true: (1) the target Spring Kafka application must be configured to use the non-blocking retry topic infrastructure, specifically via @RetryableTopic annotation or programmatic RetryTopicConfiguration - applications using only blocking retry or no retry logic are not affected; (2) the attacker must hold low-privilege Kafka producer credentials (PR:L per CVSS vector) with WRITE permission to a topic consumed by the vulnerable application - unauthenticated or anonymous producers cannot exploit this; and (3) the attacker must be able to set arbitrary Kafka message headers, which is standard behavior for any authenticated Kafka producer client. Exploitation is limited by: the opt-in nature of non-blocking retry topic configuration (not enabled by default in all Spring Kafka deployments), the requirement for authenticated producer access (PR:L), and the absence of confidentiality or integrity impact (C:N/I:N) - the effect is availability disruption of the message processing pipeline, not data exfiltration or code execution.

CVSS 6.5 (Medium) with vector AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H indicates a network-exploitable denial-of-availability condition requiring only low-privilege authentication with low attack complexity and no user interaction. The high availability impact (A:H) is the sole impact dimension - confidentiality and integrity are unaffected. Notably, the input tags classify this as 'Information Disclosure,' which directly contradicts the CVSS vector showing C:N; this discrepancy should be verified against the vendor advisory before communicating impact to stakeholders. EPSS data was not provided, limiting probabilistic exploitation forecasting. The vulnerability is not listed in CISA KEV, and no public exploit code has been identified, suggesting real-world exploitation risk is currently lower than the CVSS score alone might imply. The practical blast radius depends heavily on whether the target application uses Spring Kafka's non-blocking retry topic infrastructure, which is an opt-in feature - deployments not using @RetryableTopic or equivalent configuration are not exposed. Overall, this is a medium-priority issue for organizations running Spring Kafka with retry topic infrastructure enabled, elevated if the Kafka cluster is accessible to partially-trusted or external producers.

An attacker with low-privilege Kafka producer credentials - such as a compromised internal service account or a malicious tenant in a multi-tenant Kafka cluster - publishes a message to a topic consumed by a Spring Kafka application that has non-blocking retry topic infrastructure enabled. The message carries a crafted retry_topic-attempts header set to a large out-of-range integer, causing the retry topic router to misidentify the message's position in the retry sequence and misroute or indefinitely loop it, degrading or halting message processing for that topic. No public exploit code has been identified at time of analysis, but the attack requires only the ability to produce a valid Kafka message with a custom header, which is trivially achievable with any standard Kafka client library.