CVE-2026-59272: Log4j2 AmqpAppender disables TLS hostname verification by default
Any application shipping logs to RabbitMQ over TLS via the Log4j2 appender, relying on the documented default, is exposed to man-in-the-middle interception of every log event. Spring AMQP 4.1.0 Spring AMQP 4.0.0 - 4.0.4 Spring AMQP 3.2.0 - 3.2.12 Spring AMQP 2.4.18 and earlier
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
Spring AMQPto a version that resolves this vulnerability.Fixed in 2.4.18 - Upgrade
Upgrade
Spring AMQPto a version that resolves this vulnerability.Fixed in 3.2.0 - 3.2.12 - Upgrade
Upgrade
Spring AMQPto a version that resolves this vulnerability.Fixed in 4.0.0 - 4.0.4 - Upgrade
Upgrade
Spring AMQPto a version that resolves this vulnerability.Fixed in 4.1.0 - Configuration
Configure Log4j2 AmqpAppender to enable TLS hostname verification (the material states it disables TLS hostname verification by default).
Log4j2 AmqpAppender TLS hostname verification = enabled (do not use default that disables it)
Event History
Frequently Asked Questions
Which deployments are exposed?
Applications that ship logs to RabbitMQ over TLS through the Log4j2 AmqpAppender and rely on the documented default hostname-verification behavior are exposed. The affected Spring AMQP versions are 4.1.0, 4.0.0 through 4.0.4, 3.2.0 through 3.2.12, and 2.4.18 and earlier.
What would an attacker need to exploit this?
An attacker would need to be in a position to conduct a man-in-the-middle attack on the TLS connection between the application and RabbitMQ. Exploitation does not require user interaction, but it requires low privileges and has high attack complexity according to the supplied vector.
What data or impact is at risk?
A successful interception can expose every log event sent through the affected appender. The supplied severity vector indicates high confidentiality and integrity impact, with no availability impact.