What is the CVSS score of CVE-2026-41726?

CVE-2026-41726 has a CVSS 3.1 base score of 6.5 (Medium). CVSS vector: CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H. EPSS exploitation probability: 0.0%.

Is there a patch available for CVE-2026-41726?

Yes, a patch is available for CVE-2026-41726. Update the affected software to the latest version immediately.

Spring for Apache Kafka CVE-2026-41726

EUVD-2026-35903 MEDIUM

Allocation of Resources Without Limits or Throttling (CWE-770)

2026-06-10 security@vmware.com

GHSA-xvfq-4q6q-gxx7

Denial Of Service Apache Java Spring For Apache Kafka

6.5

CVSS 3.1 · Vendor: vmware

Severity by source

Vendor (vmware) PRIMARY

6.5 MEDIUM

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

Red Hat

6.5 MEDIUM

qualitative

Primary rating from Vendor (vmware).

CVSS VectorVendor: vmware

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

Attack Vector

Network

Attack Complexity

Low

Privileges Required

Low

User Interaction

None

Scope

Unchanged

Confidentiality

None

Integrity

None

Availability

High

Lifecycle Timeline

Patch available

Jun 10, 2026 - 02:01 EUVD

Analysis Generated

Jun 10, 2026 - 00:43 vuln.today

CVE Published

Jun 10, 2026 - 00:16 nvd

MEDIUM 6.5

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

When an application opts into DelegatingDeserializer, a producer can grow the consumer's heap without bound by sending records with unique random spring.kafka.serialization.selector header values, eventually causing GC thrash and OutOfMemoryError.

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.

AnalysisAI

Unbounded heap growth in Spring for Apache Kafka's DelegatingDeserializer allows an authenticated network producer to trigger a Denial of Service against any consumer application that opts into this deserializer. By flooding the consumer with Kafka records carrying unique, randomized spring.kafka.serialization.selector header values, an attacker forces unbounded cache growth on the consumer's JVM heap, ultimately inducing GC thrash and OutOfMemoryError. No public exploit identified at time of analysis, and this is not listed in the CISA KEV catalog, but the low-complexity, network-accessible attack surface warrants prompt remediation for affected deployments.

Technical ContextAI

Spring for Apache Kafka's DelegatingDeserializer is a pluggable deserialization facility that uses the spring.kafka.serialization.selector Kafka record header to dynamically dispatch to different deserializer implementations at runtime. The root cause is CWE-770 (Allocation of Resources Without Limits or Throttling): the framework caches or registers entries for each unique selector header value it encounters but applies no eviction policy, cap, or validation on these entries. Because header values are producer-controlled and unbounded, an adversary with producer access can inject arbitrarily large numbers of unique strings into this cache structure, growing the JVM heap without limit until garbage collection is unable to reclaim sufficient memory. The affected component is present across five major release lines of the Spring for Apache Kafka library, a widely used integration layer between Spring Boot/Framework applications and Apache Kafka. The CVSS vector (AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H) confirms this is a pure availability impact with no confidentiality or integrity consequence.

RemediationAI

The vendor advisory at https://spring.io/security/cve-2026-41726 should be consulted for confirmed fixed versions, as no explicit patch release versions were included in the input data; based on the affected ranges, versions beyond 4.0.5, 3.3.15, 3.2.13, 2.9.13, and 2.8.11 respectively are the expected fix targets but this must be verified against the advisory before upgrading. If immediate upgrade is not possible, the most actionable compensating control is to avoid opting into DelegatingDeserializer altogether - replacing it with a static deserializer implementation eliminates the vulnerable code path entirely, with the trade-off that dynamic deserialization dispatch based on record headers will no longer be available. If DelegatingDeserializer is operationally required, restricting Kafka producer ACLs to only fully trusted internal services limits the attacker population that can deliver malicious headers, though this does not eliminate the vulnerability. Additionally, JVM heap monitoring and alerting on abnormal growth, combined with consumer process restart automation, can reduce the operational impact of an exploit but should not be treated as a substitute for patching.