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

CVE-2026-41727 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.1%.

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

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

Spring Kafka CVE-2026-41727

EUVD-2026-35904 MEDIUM

Improper Input Validation (CWE-20)

2026-06-10 security@vmware.com

GHSA-53w6-v7cv-fc9h

Information Disclosure 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

Primary rating from Vendor (vmware) · only source for this CVE.

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:44 vuln.today

CVE Published

Jun 10, 2026 - 00:16 nvd

MEDIUM 6.5

DescriptionCVE.org

Spring Kafka's retry topic infrastructure did not sufficiently validate user-controlled header values before acting on them. A producer could send a record with a crafted retry_topic-attempts header to supply an out-of-range attempt count and cause the retry topic router to misidentify where the message was in the retry sequence.

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

Improper input validation in Spring for Apache Kafka's non-blocking retry topic infrastructure allows an authenticated network producer to disrupt message processing availability across multiple major version lines. By injecting a crafted retry_topic-attempts header with an out-of-range integer value, an attacker causes the retry topic router to misidentify the message's position in the retry sequence, producing high availability impact (A:H per CVSS). Affected deployments span Spring for Apache Kafka 2.8.x through 4.0.x. No active exploitation has been confirmed (not in CISA KEV) and no public exploit code has been identified at time of analysis.

Technical ContextAI

Spring for Apache Kafka's non-blocking retry topic feature routes failed messages through a series of progressively delayed retry topics by reading the retry_topic-attempts Kafka message header, a user-controlled string that encodes how many processing attempts have been made. The library uses this header to determine which retry topic to route the message to next without independently tracking state server-side. The root cause is CWE-20 (Improper Input Validation): the header value is consumed from the untrusted message payload without sufficient range or type validation before being used in routing logic. No CPE strings were provided in the input data; affected products are identified by version range only: Spring for Apache Kafka 4.0.0-4.0.5, 3.3.0-3.3.15, 3.2.0-3.2.13, 2.9.0-2.9.13, and 2.8.0-2.8.11. The vulnerability was reported by security@vmware.com, consistent with Spring's ownership under Broadcom/VMware.

RemediationAI

Consult the vendor advisory at https://spring.io/security/cve-2026-41727 for exact patched release versions across each affected branch (4.0.x, 3.3.x, 3.2.x, 2.9.x, 2.8.x); specific fix versions were not present in the provided data and upgrading to the next available release above the affected range for each branch is the primary recommended action. As a compensating control while patching, restrict Kafka ACLs so that only explicitly trusted, internal producers hold WRITE permissions on topics whose consumers use non-blocking retry topic infrastructure - this eliminates the ability of untrusted or partially-trusted producers to inject crafted headers. A second compensating option is to deploy a Kafka Streams or interceptor-based header sanitization layer that validates and clamps the retry_topic-attempts header value before records reach the Spring Kafka consumer; this adds operational complexity but does not require disabling retry functionality. If neither upgrade nor ACL restriction is immediately feasible, disabling the non-blocking retry topic feature and falling back to blocking retry (or a dead-letter topic with manual inspection) eliminates the vulnerable code path entirely, at the cost of losing retry throughput isolation.