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

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

Is there a patch available for EUVD-2026-35895?

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

Spring AMQP EUVD-2026-35895

| CVE-2026-41701 MEDIUM

Use of Insufficiently Random Values (CWE-330)

2026-06-10 security@vmware.com

GHSA-p5f7-rjhp-pxvc

Information Disclosure Java

4.4

CVSS 3.1 · Vendor: vmware

Severity by source

Vendor (vmware) PRIMARY

4.4 MEDIUM

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

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

CVSS VectorVendor: vmware

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

Attack Vector

Network

Attack Complexity

High

Privileges Required

High

User Interaction

None

Scope

Changed

Confidentiality

Low

Integrity

Low

Availability

None

Lifecycle Timeline

Patch available

Jun 10, 2026 - 02:01 EUVD

Analysis Generated

Jun 10, 2026 - 00:40 vuln.today

DescriptionCVE.org

Correlation IDs for replies in the RabbitTemplate.sendAndReceive() with the fixed reply queue are predictable due to internal simple counter.

Affected versions: Spring AMQP 4.0.0 through 4.0.3; 3.2.0 through 3.2.10; 3.1.0 through 3.1.15; 2.4.0 through 2.4.17.

AnalysisAI

Predictable correlation IDs in Spring AMQP's RabbitTemplate.sendAndReceive() expose request-reply messaging to correlation hijacking when a fixed reply queue is configured. Affected are all widely used Spring AMQP branches from 2.4.x through 4.0.x - a broad install base across Java enterprise applications. A network-positioned attacker with high privileges can exploit the sequential counter to predict future correlation IDs, enabling interception or injection of reply messages into the shared fixed reply queue. No public exploit code exists and this vulnerability is not listed in CISA KEV; CVSS 4.4 Medium reflects real-world limitations from high privilege and complexity requirements despite the changed scope indicator.

Technical ContextAI

Spring AMQP is a Java framework that abstracts AMQP/RabbitMQ messaging, and RabbitTemplate is its primary synchronous messaging abstraction. The sendAndReceive() method implements a request-reply pattern: a message is sent to an exchange and a correlated reply is expected on a reply queue. When a fixed reply queue is used (a shared, persistent queue rather than a per-request ephemeral queue), correlation IDs are the sole mechanism for matching replies to their originating requests. The root cause is CWE-330 (Use of Insufficiently Random Values): Spring AMQP internally uses a simple incrementing counter to generate these correlation IDs rather than a cryptographically secure random value. This makes IDs entirely predictable to any party that can observe even one prior message exchange. Affected CPE covers org.springframework.amqp artifacts across versions 2.4.0-2.4.17, 3.1.0-3.1.15, 3.2.0-3.2.10, and 4.0.0-4.0.3. The use of a fixed reply queue - as opposed to the default exclusive, auto-delete, temporary queue model - is a prerequisite deployment pattern.

RemediationAI

The primary remediation is to upgrade to a patched release of Spring AMQP; exact fixed versions are not confirmed from the available data and must be obtained directly from the vendor advisory at https://spring.io/security/cve-2026-41701. As an effective architectural workaround that eliminates the vulnerability entirely, applications should migrate from a fixed reply queue to per-request exclusive temporary reply queues - Spring AMQP supports this pattern natively and it removes correlation ID predictability by design, since each request gets an isolated, auto-deleted queue that cannot be observed or injected into by other parties. The trade-off of temporary queues is slightly higher broker overhead per request. A second workaround, if a fixed reply queue is architecturally required, is to implement a custom CorrelationDataPostProcessor that generates cryptographically random UUIDs (e.g., via java.util.UUID.randomUUID()) as correlation IDs rather than relying on the internal counter. This approach carries no functional trade-off but requires code changes and testing. Patch availability as a released artifact version is not independently confirmed from this data set - consult the Spring advisory before assuming any specific version is remediated.