CVE-2026-41714: Spring AMQP TLS Validation Vulnerability

CVE-2026-41714 Overview

CVE-2026-41714 affects Spring AMQP applications that configure broker connections through RabbitConnectionFactoryBean.setUri("amqps://...") without explicitly invoking setUseSSL(true). In this configuration, the resulting TLS connection skips certificate validation and hostname verification. The flaw maps to improper certificate validation [CWE-295]. Attackers positioned on the network path can intercept or modify AMQP traffic that operators expected to be authenticated by TLS. The issue affects Spring AMQP 4.0.0 through 4.0.3, 3.2.0 through 3.2.10, 3.1.0 through 3.1.15, and 2.4.0 through 2.4.17.

Critical Impact
Spring AMQP clients establish encrypted but unauthenticated TLS sessions to RabbitMQ brokers, exposing credentials and message data to man-in-the-middle attackers.

Affected Products

Spring AMQP 4.0.0 through 4.0.3
Spring AMQP 3.2.0 through 3.2.10 and 3.1.0 through 3.1.15
Spring AMQP 2.4.0 through 2.4.17

Discovery Timeline

2026-06-10 - CVE-2026-41714 published to NVD
2026-06-10 - Last updated in NVD database

Technical Details for CVE-2026-41714

Vulnerability Analysis

Spring AMQP exposes RabbitConnectionFactoryBean as the standard way to construct a ConnectionFactory for RabbitMQ clients. Developers commonly call setUri("amqps://host:5671") and expect the amqps scheme to enable a fully validated TLS session. The bean does enable TLS transport when it parses the URI, but it does not internally flip the useSSL flag that drives certificate and hostname verification. As a result, the client negotiates TLS but accepts any server certificate, including self-signed or attacker-controlled certificates. An attacker who can redirect traffic between the application and the broker can decrypt credentials, AMQP exchanges, and message payloads.

Root Cause

The defect lives in the configuration logic of RabbitConnectionFactoryBean. The code path that handles setUri for amqps URIs does not align with the code path triggered by setUseSSL(true), which installs the validating SSLContext. When only setUri is called, the factory falls back to a default SSLContext that performs no peer verification. The mismatch between the two configuration entry points is the underlying improper certificate validation issue.

Attack Vector

Exploitation requires a network position between the Spring AMQP client and the RabbitMQ broker, for example through ARP spoofing, rogue DNS, BGP hijack, or compromised intermediate infrastructure. The attacker presents any TLS certificate to the client, completes the handshake, and proxies or modifies the AMQP frames. The Spring application treats the session as trusted and transmits broker credentials and message bodies through the attacker. The attack complexity is elevated because it depends on the adversary gaining an on-path position, but no user interaction or authentication is required against the Spring client itself.

No public proof-of-concept code is published for this issue. Refer to the Spring CVE-2026-41714 Advisory for vendor technical details.

Detection Methods for CVE-2026-41714

Indicators of Compromise

AMQP sessions to the broker terminating on certificates that are not signed by the organization's expected certificate authority.
Unexpected TLS handshakes between application hosts and IP addresses that are not the production RabbitMQ broker.
RabbitMQ broker logs showing client connections that lack expected SNI values or originate from unexpected upstream proxies.

Detection Strategies

Inventory application code and Spring Boot configurations for use of RabbitConnectionFactoryBean.setUri with an amqps:// scheme and no corresponding setUseSSL(true) call.
Scan dependency manifests (pom.xml, build.gradle) for vulnerable spring-amqp and spring-rabbit versions in the affected ranges.
Use TLS inspection or passive certificate logging on egress traffic to flag AMQP sessions where the presented certificate chain does not match the expected broker certificate.

Monitoring Recommendations

Forward RabbitMQ broker access logs and Spring application TLS handshake events into a centralized log platform for correlation against known-good certificate fingerprints.
Alert on new or changing server certificate hashes observed on port 5671 from application hosts.
Track outbound connections from microservices to ensure AMQP traffic only reaches authorized broker endpoints.

How to Mitigate CVE-2026-41714

Immediate Actions Required

Upgrade Spring AMQP to a fixed release line above 4.0.3, 3.2.10, 3.1.15, or 2.4.17 as listed in the vendor advisory.
Audit every RabbitConnectionFactoryBean usage and add an explicit setUseSSL(true) call when an amqps URI is configured.
Rotate any RabbitMQ credentials that may have transited an unvalidated TLS session.

Patch Information

Pivotal/Spring published fixed Spring AMQP releases that address the misconfiguration so that an amqps URI alone enables full certificate and hostname validation. Apply the patched version that matches your current branch and rebuild dependent services. Consult the Spring CVE-2026-41714 Advisory for the specific fixed versions and release notes.

Workarounds

Explicitly invoke setUseSSL(true) on every RabbitConnectionFactoryBean instance alongside setUri("amqps://...").
Configure the factory with an explicit SSLContext and trust store that pins the broker's certificate authority.
Restrict AMQP egress to the broker's IP address and require mTLS at the broker so unauthenticated clients cannot complete the handshake.

bash

# Configuration example: enforce TLS validation when building the factory
# RabbitConnectionFactoryBean factory = new RabbitConnectionFactoryBean();
# factory.setUri("amqps://broker.example.com:5671");
# factory.setUseSSL(true);
# factory.setSslAlgorithm("TLSv1.3");
# factory.setTrustStore("classpath:truststore.jks");
# factory.setTrustStorePassphrase("changeit");
# factory.setSkipServerCertificateValidation(false);
# factory.setEnableHostnameVerification(true);