Attack ChainAIDerived
Hypothetical attack flow derived from CVE metadata – not a confirmed exploit chain
-
AccessGain produce access to target topic
-
DeliveryCraft header with malicious type FQCN under trusted-package prefix
-
ExploitEmbed gadget-triggering JSON payload
-
ExecutionConsumer header mapper accepts type
-
PersistJackson deserializes attacker-controlled class
-
ImpactGadget chain executes code in consumer JVM
Vulnerability Assessment
| Weakness |
CWE
OWASP Top 10:2025
A08:2025 - Software or Data Integrity Failures
ASVS 5.0
V1 - Encoding and Sanitization Safe deserialization, type allowlists
MITRE ATT&CK
2 techniques across 2 tactics: Execution, Initial Access The technique list with ATT&CK links and the kill-chain view is part of the Basic plan and up. |
| Exploitation Conditions | Exploitation requires the attacker to be able to produce messages to a Kafka topic that a vulnerable Spring for Apache Kafka consumer reads, with that consumer configured to use JsonKafkaHeaderMapper or DefaultKafkaHeaderMapper for header type mapping. The consumer must have at least one entry in its trustedPackages list that is a prefix of (or shares a prefix with) an attacker-reachable class, and Jackson default bean deserialization must be in effect (the default for these mappers). Reaching arbitrary code execution further requires exploitable gadget classes on the consumer classpath; without suitable gadgets the impact may degrade to type confusion or denial of service. Limiting factors: closed/internal Kafka clusters where all producers are trusted, ACL-restricted topics, consumers that have replaced the default header mapper with a strict type allowlist, and the AC:H rating in the CVSS vector all reduce realistic exposure. |
| Impact | CVSS 8.1 (AV:N/AC:H/PR:N/UI:N/C:H/I:H/A:H) reflects an unauthenticated, network-reachable attack with high impact across CIA, mitigated by high attack complexity. The complexity rating is appropriate: the attacker must already be able to publish to a topic the victim consumes, and successful code execution depends on exploitable gadgets being present on the consumer classpath - both real but non-trivial preconditions. EPSS, KEV, and SSVC data were not supplied for this CVE, so prioritization must lean on the CVSS vector and the well-known severity of Jackson default-typing deserialization rather than on observed exploitation. No public PoC was identified in the provided references; this should not be treated as zero-day, but the bug pattern is well-understood and gadget chains are widely documented, so weaponization by a motivated attacker is plausible once the advisory text is parsed. Net assessment: high-priority patch for any deployment where Kafka producers and consumers cross trust boundaries (multi-tenant clusters, ingestion from partner systems, internet-exposed brokers); lower urgency where producers are fully controlled and isolated. |
| Exploit ScenarioDerived | An attacker who can publish records to a Kafka topic consumed by a vulnerable Spring application crafts a message header whose declared Java type points to a class in a subpackage of any trusted package (or one matching the prefix), with a JSON value that drives Jackson's default bean deserialization into a gadget chain present on the consumer classpath. When the consumer reads the record, the header mapper accepts the type, Jackson constructs the attacker-chosen object, and side effects of that construction yield arbitrary code execution or sensitive data disclosure in the consumer JVM. No public PoC was identified in the supplied references, but the pattern mirrors prior Jackson default-typing exploits. |
Get an e-mail when this CVE is exploited, patched or re-scored. Free account.
Alert meAnalysisAIv1 – Jun 10, 2026
Unsafe deserialization in Spring for Apache Kafka (versions 2.8.0-4.0.5 across multiple branches) allows a malicious Kafka producer to send crafted message headers that cause downstream consumers to instantiate arbitrary JDK types via Jackson. The flaw stems from a prefix-based trusted-packages check in JsonKafkaHeaderMapper and the deprecated DefaultKafkaHeaderMapper, which silently extends trust to every subpackage. No public exploit identified at time of analysis, but the bug class (CWE-502 with Jackson default typing) has a long history of leading to remote code execution in Spring/Java ecosystems.
RemediationAI
Upgrade Spring for Apache Kafka to a fixed release on your branch - consult the Spring advisory at https://spring.io/security/cve-2026-41731 for the exact patched versions, since the input data lists only the vulnerable ranges and a specific fixed build number was not independently confirmed here. As a configuration-level mitigation, tighten the trusted-packages list to the narrowest set possible and avoid wildcard or short prefixes; better still, migrate off DefaultKafkaHeaderMapper (already deprecated) to a mapper configured with an explicit allowlist of fully-qualified type names rather than packages, or disable JSON type-header mapping entirely and rely on a fixed deserializer per topic - the trade-off is loss of polymorphic header typing and some code changes to producers/consumers. Where patching is delayed, restrict who can publish to consumed topics via Kafka ACLs and network segmentation so untrusted producers cannot reach the affected consumers, and audit the consumer classpath to remove known Jackson/Java deserialization gadget libraries.
Affected VersionsENISA
Affected Packages
Source: OSV (Open Source Vulnerabilities)
Affects your stack
Affects 2 packages in maven, euvd
Checking this CVE against your own stacks and servers is part of the Basic plan and up.
Technical ContextAI · show details
Spring for Apache Kafka provides header mappers that translate Kafka record headers into typed Java objects on the consumer side. JsonKafkaHeaderMapper (and the older DefaultKafkaHeaderMapper) lets operators configure a list of 'trusted packages' so only headers whose declared Java type lives in those packages will be deserialized via Jackson. The vulnerability is that the implementation matches the header's type FQCN against the trusted list using a simple prefix/startsWith comparison rather than exact package equality. Trusting 'com.example' therefore also trusts 'com.example.evil', and more dangerously, trusting any common prefix (or a package whose name is a prefix of an attacker-controlled one) widens the allowlist far beyond intent. Combined with Jackson's default bean deserialization semantics, a producer fully controls the Java class instantiated by the consumer, which is the canonical CWE-502 insecure-deserialization pattern that, depending on classpath gadgets, typically escalates from data tampering to remote code execution.
Know when Spring For Apache Kafka gets its next vulnerability
- Watch products and get an email when something new is published
- Check this CVE against your own stack and servers
- Exploit and PoC references, threat intelligence from 22 sources
No credit card · 7-day full trial
Severity by source
AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H
Primary rating from Vendor (vmware).
CVSS VectorVendor: vmware
Lifecycle Timeline
2DescriptionCVE.org
JsonKafkaHeaderMapper and the deprecated DefaultKafkaHeaderMapper matched type headers against trusted packages using a prefix check, meaning that trusting any package implicitly trusted all of its subpackages. Combined with Jackson's default bean deserialization, a producer could supply crafted header values that caused the consumer to deserialize arbitrary JDK types.
Affected versions: Spring for Apache Kafka 4.0.0 through 4.0.5; 3.3.0 through 3.3.15; 3.2.0 through 3.2.13; 2.9.0 through 2.9.13; 2.8.0 through 2.8.11.
Blast Radius
ecosystem impact- 32 maven packages depend on org.springframework.kafka:spring-kafka (10 direct, 22 indirect)
Ecosystem-wide dependent count for version 4.0.0.
Articles & Coverage 1
Executive ViewAI
Spring for Apache Kafka versions 2.8.0-4.0.5 contain a critical unsafe deserialization vulnerability in message header handling that allows malicious Kafka producers to achieve remote code execution on downstream consumers. Organizations operating these vulnerable versions face complete data pipeline compromise and code execution across consumer infrastructure, with no vendor-released patches currently available for remediation.
No vendor-released patch identified at time of analysis. Interim mitigations include: (1) Restrict Kafka producer access through authentication and network segmentation to only trusted services; (2) Disable or isolate JsonKafkaHeaderMapper functionality if not required; (3) Implement message header validation and filtering before deserialization; (4) Monitor Kafka traffic for suspicious serialized object patterns in headers; (5) Run Kafka consumers in isolated containers with minimal privileges to limit blast radius if exploitation occurs.
Threat Intelligence Overview
How this decision was reached
The engine reads each signal below and applies a fixed list of rules from top to bottom. The first rule that matches sets the recommended action – like a statement, every line is shown.
What every action level means
SSVC AssessmentENISA
Priority Score
Attack Technique
Insecure deserialization occurs when an application converts serialized data (a stream of bytes representing an object's state) back into a living object without proper validation.
Related Vulnerabilities in Spring Kafka Deserialization and Validation Flaws
View all 3More in Spring For Apache Kafka
View allIn Spring for Apache Kafka 3.0.9 and earlier and versions 2.9.10 and earlier, a possible deserialization attack vector e
Denial-of-service in Spring for Apache Kafka's `DeadLetterPublishingRecovererFactory` exposes consumer JVMs across all s
Header type injection in Spring for Apache Kafka's default mapper configuration allows any Kafka producer with access to
EUVD-2026-35908
GHSA-xq69-5h5v-x9x4
NVD
CVE.org
EPSS
Vulnrichment
VulDB
Exploit-DB