CVE-2026-59272

Overview

Spring AMQP applies core Spring concepts to the development of AMQP-based messaging solutions, providing a template abstraction for publishing and receiving messages, listener containers for asynchronous consumption, and support classes for declaring RabbitMQ exchanges, queues, and bindings.

An Incorrectly Configured Access Control vulnerability (CVE-2026-59272) has been identified in the Log4j2 AmqpAppender of Spring AMQP, which allows attackers positioned on the network path to intercept or alter log traffic sent over TLS, because certificate hostname verification is silently off unless the attribute is set explicitly.

Per CWE: The product communicates with a host that provides a certificate, but the product does not properly ensure that the certificate is actually associated with that host. Even if a certificate is well-formed, signed, and follows the chain of trust, it may simply be a valid certificate for a different site than the site that the product is interacting with.

This issue affects the Log4j2 appender support of Spring AMQP.

Details

Module Info

• Product: Spring AMQP
• Affected packages: org.springframework.amqp:spring-rabbit
• Affected versions: >= 2.1.7 <= 2.4.18, >= 3.0.0 <= 3.2.12, >= 4.0.0 <= 4.0.4, 4.1.0
• 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: nes-v2.3.21, nes-v2.4.28, nes-v3.1.20, and nes-v3.2.14
  • OSS Spring AMQP 4.0.5 and 4.1.1

Vulnerability Info

This Medium-severity vulnerability is found in the org.springframework.amqp:spring-rabbit package in the Log4j2 appender support of Spring AMQP.

The appender manager documents and defaults hostname verification to on, but the plugin builder that constructs it declares the same setting as a bare primitive, so it starts out false whenever the attribute is omitted from the Log4j2 configuration:

// AmqpManager
private boolean verifyHostname = true;

// AmqpAppender.Builder
@PluginBuilderAttribute("useSsl")
private boolean useSsl;

@PluginBuilderAttribute("verifyHostname")
private boolean verifyHostname;

The builder then pushes its own value onto the manager unconditionally, because the primitive boxes to Boolean.FALSE and passes the not-null test:

.acceptIfNotNull(this.verifyHostname, value -> manager.verifyHostname = value)

The manager's secure default is therefore always overwritten with false, and the connection factory is configured with hostname verification disabled:

if (this.useSsl) {
    factoryBean.setUseSSL(true);
    factoryBean.setEnableHostnameVerification(this.verifyHostname);
    ...
}

Any application shipping logs to RabbitMQ over TLS through this appender and relying on the documented default therefore negotiates a session whose certificate is never bound to the expected hostname. An attacker on the network path can present any valid certificate and read or modify every log event, which frequently carries tokens, personal data, or stack traces containing secrets, and no certificate error is raised to alert operators.

The same builder also left the sender pool size, maximum sender retries, and durable settings at primitive defaults rather than their documented values.

Mitigation

Only recent versions of Spring AMQP receive community support. Older lines are End-of-Life and will not receive public updates to address this issue.

Users of the affected components should apply one of the following mitigations:

• Set verifyHostname="true" explicitly on the Log4j2 AmqpAppender configuration, which restores certificate hostname verification without an upgrade.
• Upgrade to a currently supported version of Spring AMQP.
• Leverage a commercial support partner like HeroDevs for post-EOL security support.

Credits

• No external finder is named in the upstream advisory for this issue.