What is the CVSS score of EUVD-2026-35908?

EUVD-2026-35908 has a CVSS 3.1 base score of 8.1 (High). CVSS vector: CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H. EPSS exploitation probability: 0.0%.

Which versions of Spring for Apache Kafka are affected by EUVD-2026-35908?

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…. A patch is available.

How to fix or mitigate EUVD-2026-35908?

24 HOURS: Identify systems running Spring for Apache Kafka versions 2.8.0-4.0.5. Strengthen Kafka producer access controls through authentication and network segmentation to restrict producers to trusted sources only. 7 DAYS: Monitor Spring for Apache Kafka advisories for patched versions. Implement compensating controls if upgrades are not available. Test in staging environment. 30 DAYS: Deploy patched Spring for Apache Kafka versions when available, or complete production deployment of compensating controls and establish continuous monitoring for suspicious message header patterns.

Spring for Apache Kafka EUVD-2026-35908

| CVE-2026-41731 HIGH

Deserialization of Untrusted Data (CWE-502)

2026-06-10 security@vmware.com

GHSA-xq69-5h5v-x9x4

Deserialization Apache Java Spring For Apache Kafka

8.1

CVSS 3.1 · Vendor: vmware

Severity by source

Vendor (vmware) PRIMARY

8.1 HIGH

AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H

Red Hat

8.1 HIGH

qualitative

Primary rating from Vendor (vmware).

CVSS VectorVendor: vmware

CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H

Attack Vector

Network

Attack Complexity

High

Privileges Required

None

User Interaction

None

Scope

Unchanged

Confidentiality

High

Integrity

High

Availability

High

Lifecycle Timeline

Patch available

Jun 10, 2026 - 02:01 EUVD

Analysis Generated

Jun 10, 2026 - 00:35 vuln.today

CVE Published

Jun 10, 2026 - 00:16 nvd

HIGH 8.1

Blast Radius

ecosystem impact

† from your stack dependencies † transitive graph · vuln.today resolves 4-path depth

32 maven packages depend on org.springframework.kafka:spring-kafka (10 direct, 22 indirect)

Ecosystem-wide dependent count for version 4.0.0.

DescriptionCVE.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.

Articles & Coverage 1

News 11 New Apache Vulnerabilities - 4 Critical, 7 High Severity Jun 10, 2026

AnalysisAI

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.

Technical ContextAI

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.

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.