Spring for Apache Kafka EUVD-2026-35903

The application must explicitly opt into Spring for Apache Kafka's DelegatingDeserializer - this is not the default configuration, so deployments using standard StringDeserializer, JsonDeserializer, or other non-delegating implementations are not vulnerable. The attacker must hold authenticated Kafka producer credentials (PR:L per CVSS vector) with write access to at least one topic that the target consumer subscribes to. No special platform, OS, or additional configuration beyond the DelegatingDeserializer opt-in is required. Exploitation is limited by: (1) the authentication barrier for Kafka producer access, (2) the non-default nature of DelegatingDeserializer, and (3) the scoped blast radius - only the JVM process running the consumer is affected, not other services or the Kafka broker itself. There is no user interaction requirement and no constraint on the network path beyond reachability to the Kafka cluster.

The CVSS base score of 6.5 (Medium) is broadly accurate for this class of vulnerability. The vector AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H indicates the attack is network-reachable, requires no special conditions or user interaction, but does require low-privilege authentication (PR:L) - meaning the attacker must be an authenticated Kafka producer with write access to a topic the target consumer is subscribed to. This is a meaningful barrier in well-secured environments but is trivially satisfied in multi-tenant Kafka clusters or cases where producer credentials are broadly distributed. No KEV listing and no public exploit code identified at time of analysis, making this unlikely to be opportunistically exploited at scale currently; however, the attack is straightforward to implement manually without sophisticated tooling. The impact is scoped to the consumer JVM process (S:U), so the blast radius is limited to availability of the consuming application rather than infrastructure-wide impact. The combination of low attack complexity and high availability impact means that once an attacker has producer credentials, exploitation is reliable. Priority should be highest for internet-exposed Kafka consumers or multi-tenant deployments where producer trust boundaries are weak.

An attacker with authenticated Kafka producer credentials - for instance, a compromised microservice or a malicious tenant in a shared Kafka cluster - writes a high-volume stream of records to a topic consumed by a target Spring application using DelegatingDeserializer. Each record carries a different randomly generated spring.kafka.serialization.selector header value, causing the consumer to accumulate unbounded cache entries on its JVM heap. Over time, heap exhaustion triggers increasingly severe GC pauses and ultimately an OutOfMemoryError, crashing the consumer process. No public exploit code has been identified at time of analysis, but the attack requires only standard Kafka producer APIs and is trivially scriptable.