CVE-2026-41731: Spring for Apache Kafka RCE Vulnerability

CVE-2026-41731 Overview

CVE-2026-41731 is an insecure deserialization vulnerability [CWE-502] in Spring for Apache Kafka. The JsonKafkaHeaderMapper and the deprecated DefaultKafkaHeaderMapper matched type headers against trusted packages using a prefix check. Trusting any package implicitly trusted all of its subpackages. Combined with Jackson's default bean deserialization, a malicious producer could supply crafted header values that caused the consumer to deserialize arbitrary JDK types.

The flaw affects multiple supported branches of Spring for Apache Kafka, exposing consumer applications to remote code execution risks when processing untrusted Kafka messages.

Critical Impact
Attackers controlling Kafka producers can trigger arbitrary deserialization on consumer applications, potentially leading to remote code execution and full compromise of consumer services.

Affected Products

Spring for Apache Kafka 4.0.0 through 4.0.5
Spring for Apache Kafka 3.3.0 through 3.3.15, and 3.2.0 through 3.2.13
Spring for Apache Kafka 2.9.0 through 2.9.13, and 2.8.0 through 2.8.11

Discovery Timeline

2026-06-10 - CVE-2026-41731 published to NVD
2026-06-10 - Last updated in NVD database

Technical Details for CVE-2026-41731

Vulnerability Analysis

Spring for Apache Kafka provides header mappers that translate Kafka message headers into Java types on the consumer side. The JsonKafkaHeaderMapper and the deprecated DefaultKafkaHeaderMapper consult a list of trusted packages before deserializing header payloads via Jackson.

The trust check uses a string prefix comparison rather than exact package matching. Trusting com.example therefore also trusts com.example.evil, com.example.attacker.gadgets, and any other subpackage. Attackers exploit this by routing types through subpackages that share a prefix with a legitimately trusted root.

Jackson's default bean deserialization compounds the issue. Once a type passes the prefix check, Jackson instantiates the class and populates its fields, invoking setters and constructors. This pathway permits gadget chains against arbitrary JDK types reachable from the consumer classpath.

Root Cause

The root cause is improper validation of deserialization input. The trusted package list was enforced as a prefix match instead of a strict equality or hierarchical containment check. This logic flaw broke the security boundary the trusted package list was designed to enforce.

Attack Vector

Exploitation requires the attacker to send Kafka messages to a topic consumed by a vulnerable application. The producer sets the __TypeId__ or related type header to a fully qualified class name in a subpackage of a trusted root. The consumer's header mapper accepts the type, and Jackson deserializes attacker-controlled JSON into that class, triggering side effects in setters, constructors, or gadget chains.

The attack vector is network-based and requires no authentication on the vulnerability itself, though the attacker must be able to publish to a topic the victim consumes. See the Spring Security advisory for CVE-2026-41731 for technical details.

Detection Methods for CVE-2026-41731

Indicators of Compromise

Kafka headers containing fully qualified Java class names in subpackages of configured trusted roots, particularly classes not used by the application's normal message contracts.
Consumer process activity spawning unexpected child processes, performing outbound network connections, or loading unusual JDK classes shortly after message consumption.
Jackson deserialization stack traces in consumer logs referencing classes outside expected domain packages.

Detection Strategies

Inventory all services using spring-kafka and identify configured trusted packages in JsonKafkaHeaderMapper or DefaultKafkaHeaderMapper instances.
Inspect Kafka broker logs or message samples for type headers referencing unexpected package paths under trusted prefixes.
Deploy runtime application self-protection or Java agents to alert on Jackson deserialization of unexpected polymorphic types.

Monitoring Recommendations

Log and review all __TypeId__ header values received by consumers and alert on deviations from an allow-list of expected message types.
Monitor consumer JVMs for anomalous process, file, or network activity that correlates with message consumption events.
Forward Kafka client and JVM telemetry to a centralized analytics platform to correlate suspicious deserialization patterns across services.

How to Mitigate CVE-2026-41731

Immediate Actions Required

Upgrade Spring for Apache Kafka to a patched release on your supported branch as listed in the Spring advisory.
Audit and tighten trusted package configuration on every JsonKafkaHeaderMapper and DefaultKafkaHeaderMapper to the narrowest set of fully qualified packages required.
Restrict Kafka topic produce permissions so only authenticated, authorized services can publish to topics consumed by sensitive applications.

Patch Information

Pivotal has released fixed versions across all maintained branches. Consult the Spring Security advisory for CVE-2026-41731 for the exact patched build for versions 4.0.x, 3.3.x, 3.2.x, 2.9.x, and 2.8.x. The fix replaces prefix matching with strict package validation in the header mappers.

Workarounds

Migrate away from the deprecated DefaultKafkaHeaderMapper to JsonKafkaHeaderMapper and apply the patched release.
Configure a custom KafkaHeaderMapper that performs exact package or class-name matching against an explicit allow-list rather than relying on prefix logic.
Disable Jackson default typing and enforce a PolymorphicTypeValidator that restricts deserialization to a known set of safe domain classes.

bash

# Example: tighten Spring Kafka consumer trusted packages
spring.kafka.consumer.properties.spring.json.trusted.packages=com.example.messaging.events
# Avoid using a broad root such as com.example which would trust all subpackages