CVE-2026-41714
This Vulnerability has been fixed in the Never-Ending Support (NES) version offered by HeroDevs.
Overview
Spring AMQP is the Spring portfolio's messaging library for RabbitMQ, providing the connection, template, and listener abstractions that Spring applications use to publish and consume AMQP messages. RabbitConnectionFactoryBean is the factory bean that builds the underlying RabbitMQ client connection factory from declarative configuration, including the broker URI.
A medium-severity vulnerability (CVE-2026-41714) has been identified in Spring AMQP. When an application configures the broker connection with an amqps:// URI through RabbitConnectionFactoryBean.setUri(...) but does not also call setUseSSL(true), the bean passes the URI straight to the underlying RabbitMQ client. The client opens a TLS connection on the secure port, but it does so with a permissive default SSL context that performs no certificate validation and no hostname verification, and Spring AMQP's own SSL configuration path is never engaged. The connection is therefore encrypted but unauthenticated: an attacker positioned on the network can present any certificate, complete the handshake, and intercept or relay the channel, exposing the broker credentials and message traffic carried over it.
Per OWASP, insecure transport occurs when an application transmits sensitive data over a channel that does not properly authenticate the endpoint, allowing an attacker to read or modify the data in transit even when encryption is nominally in use.
This issue affects >=2.3.0 <=2.3.16, >=2.4.0 <=2.4.17, >=3.1.0 <=3.1.16, >=3.2.0 <=3.2.10, and >=4.0.0 <=4.0.3 of Spring AMQP.
Details
Module Info
- Product: Spring AMQP
- Affected packages: spring-rabbit
- Affected versions: >=2.3.0 <=2.3.16, >=2.4.0 <=2.4.17, >=3.1.0 <=3.1.16, >=3.2.0 <=3.2.10, >=4.0.0 <=4.0.3
- GitHub repository: https://github.com/spring-projects/spring-amqp
- Published packages: https://central.sonatype.com/artifact/org.springframework.amqp/spring-rabbit
- Package manager: Maven
- Fixed in:
- NES for Spring AMQP 2.3.x, 2.4.x, 3.1.x, 3.2.x
- Spring AMQP 4.0.4, 3.2.11 (OSS)
Vulnerability Info
RabbitConnectionFactoryBean wraps the RabbitMQ Java client's ConnectionFactory. Its setUri methods forwarded the supplied URI directly to that client factor.
public void setUri(URI uri) {
try {
this.connectionFactory.setUri(uri);
}
catch (URISyntaxException | NoSuchAlgorithmException | KeyManagementException e) {
throw new IllegalArgumentException("Unable to set uri", e);
}
}
When the URI scheme is amqps, the RabbitMQ client switches to the TLS port and enables SSL on its own, but it uses a default SSL context with no trust manager and no hostname verification, so the broker certificate is never validated. Routing the URI this way also bypasses Spring AMQP's setUpSSL() method, which is the code that installs a real trust store and key store and applies hostname verification. That method only runs when the bean's useSSL flag is set, and useSSL was set only by an explicit setUseSSL(true) call. An application that relied on the amqps scheme alone to secure the connection therefore obtained an encrypted but unauthenticated channel, vulnerable to a man-in-the-middle who can substitute any certificate. The same flaw was present in the log4j2 and logback AmqpAppender components, which build a connection factory bean from a configured URI.
This vulnerability has been present since at least Spring AMQP 2.3 and likely earlier.
Mitigation
Spring AMQP versions 3.2.x and 4.0.x receive the fix in the open-source releases 3.2.11 and 4.0.4; versions 2.4.x and 3.1.x are past their open-source support window and have no publicly available fix. Users still running an affected open-source line that no longer receives free updates should not attempt to hand-patch the connection-factory internals.
To remediate this issue, affected users have two recommended options:
- Upgrade to a supported, fixed release of Spring AMQP.
- Adopt HeroDevs Never-Ending Support (NES) for Spring AMQP, which provides a drop-in compatible build with this vulnerability fixed for release lines that are otherwise end-of-life, with no code changes required. Learn more about HeroDevs Never-Ending Support for Spring AMQP and request coverage at https://www.herodevs.com/support/spring-nes.
Credits
- This issue was identified and resolved internally by the Spring AMQP team.