Spring Boot CVE-2026-40971

Exploitation is contingent on two specific conditions both being true: (1) the Spring Boot application must be configured to use an SSL bundle for RabbitMQ - specifically, the auto-configuration path triggered by the SSL bundle feature introduced in Spring Boot 3.1+ must be active, meaning a spring.ssl.bundle.* definition is referenced by the RabbitMQ configuration; applications using raw truststore properties or no TLS are not affected. (2) The attacker must occupy an adjacent network position - same broadcast domain, VLAN, or routed segment - from which they can intercept the TCP connection to the RabbitMQ broker before it reaches its destination. Limiting factors: the adjacent-network requirement eliminates remote internet threat actors; high attack complexity means opportunistic or automated exploitation is not viable; no authentication credential is required on the attacker side, but network positioning is mandatory. Applications not using SSL bundles for RabbitMQ are entirely unaffected regardless of Spring Boot version.

The CVSS 3.1 vector AV:A/AC:H/PR:N/UI:N/S:U/C:L/I:L/A:L produces a score of 5.0, reflecting moderate concern tempered by meaningful constraints. The adjacent-network attack vector (AV:A) requires the attacker to be on the same broadcast domain or routed segment as the Spring Boot application, ruling out remote internet exploitation. High attack complexity (AC:H) further requires the adversary to be correctly positioned to intercept a TLS handshake at the right moment. All three impact dimensions are Low, consistent with partial read and inject capabilities over the RabbitMQ channel rather than full system compromise. Corroborating signals: EPSS at 0.01% places this in the 3rd percentile of exploitation likelihood; SSVC marks exploitation as none and automatable as no, meaning mass exploitation tooling does not exist. The net assessment is that this is a real but low-urgency vulnerability - important to patch in environments where RabbitMQ carries sensitive business messages, but not an emergency given the required network proximity and configuration prerequisite. No data conflicts exist between CVSS, EPSS, and SSVC signals in this case.

An attacker with a foothold on the same network segment - for example, a compromised container in the same Kubernetes namespace or a rogue host on the same VLAN - intercepts the outbound TLS connection from the Spring Boot application to the RabbitMQ broker. Because hostname verification is absent, the attacker presents a self-signed or stolen certificate with a mismatched hostname, completes the handshake, and proxies traffic to a real broker. This gives the attacker the ability to read AMQP messages in transit and potentially inject fabricated messages into the queue. No public proof-of-concept code has been identified at time of analysis.