Spring for Apache Kafka CVE-2026-59278

Three concrete conditions must hold simultaneously: the target application must use @KafkaListener consumers (the idiomatic Spring Kafka pattern); must use JsonKafkaHeaderMapper or DefaultKafkaHeaderMapper without an explicit setTrustedPackages() call that excludes java.net (the default for all Spring Kafka consumers - no misconfiguration required); and the attacker must have the ability to produce messages to a Kafka topic the target application is subscribed to. The third condition - Kafka producer access - is the primary limiting factor and separates this from a trivially internet-exploitable flaw. Kafka brokers with no producer ACLs or with broad internal service account permissions are most at risk. Applications that have already configured a restrictive trusted-packages allowlist are not affected regardless of version. There are no platform, OS, or Java runtime version prerequisites beyond running Spring Kafka in the affected version range.

The CVSS 6.5 Medium score (AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:N) reflects a broadly exploitable surface: any party able to produce messages to a Kafka topic the target subscribes to can trigger the flaw with no authentication and minimal complexity. In practice, Kafka brokers are rarely exposed to the open internet and typically reside on internal networks with some degree of access control, meaning the PR:N/AV:N combination overstates practical accessibility for most deployments - broker-level producer ACLs are a meaningful real-world barrier. The primary exploitation outcome is DNS-based SSRF via InetAddress instantiation, enabling internal network reconnaissance and potential data exfiltration via DNS channels rather than direct code execution, which contextualizes the C:L/I:L impact ratings. No EPSS score is present in the supplied intelligence. The CVE is not in CISA KEV and no POC has been identified, placing SSVC exploitation status at 'none (active)' at time of analysis. The broadest real-world risk factor is the default-configuration footprint: every @KafkaListener deployment using stock Spring Kafka is affected without any misconfiguration on the developer's part, making the aggregate exposure surface large even if individual exploitation requires broker access.

An attacker with producer access to a Kafka topic consumed by the target application sends a crafted message with the spring_json_header_types header set to java.net.InetAddress and a header value containing an attacker-controlled hostname. The @KafkaListener's DefaultKafkaHeaderMapper, trusting java.net by default, deserializes the value as an InetAddress object, triggering an outbound DNS resolution to the attacker's domain. The attacker observes the DNS query, confirming the consumer host's identity, internal reachability, and potentially exfiltrating small amounts of data encoded in DNS subdomains. No public POC has been identified, but exploitation requires only standard Kafka producer API calls.