Vulnerability Directory | CVE-2026-41701

Overview

Spring AMQP is the Spring portfolio project that applies core Spring concepts to AMQP-based messaging, providing the RabbitTemplate for sending and receiving messages with RabbitMQ. Its request/reply support lets an application send a message and block for the matching reply, correlating each reply back to its pending request through a generated correlation identifier.

A medium-severity vulnerability (CVE-2026-41701) has been identified in Spring AMQP. When RabbitTemplate.sendAndReceive() is used with a fixed reply queue, the correlation identifier that ties each reply to its request is generated from a simple per-instance integer counter rather than a random value. These identifiers are therefore sequential and predictable, and two RabbitTemplate instances consuming from the same fixed reply queue each begin counting from the same starting point, so their identifier spaces overlap. An actor able to publish to the shared reply queue can supply a guessable correlation identifier to steal a reply intended for another requester or to inject a forged reply that the legitimate requester accepts, an attack known as reply poisoning.

Per OWASP, insecure randomness occurs when a function that produces predictable values is used in a security-sensitive context, allowing an attacker who can determine the next value to undermine the protection it was meant to provide.

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

Spring AMQP's request/reply support correlates each reply back to its pending request using a messageTag value. When a fixed reply queue is configured, RabbitTemplate generated that tag from a process-local AtomicInteger counter, incrementing it for each request:

private final AtomicInteger messageTagProvider = new AtomicInteger();

// ...
String messageTag = String.valueOf(RabbitTemplate.this.messageTagProvider.incrementAndGet());
RabbitTemplate.this.replyHolder.putIfAbsent(messageTag, pendingReply);

‍‍The resulting correlation identifiers are sequential (1, 2, 3, ...) and therefore predictable. Because the counter is scoped to a single RabbitTemplate instance and resets to zero when the instance is created, multiple templates that share one fixed reply queue produce overlapping identifier spaces: a reply carrying a given correlation identifier can match a pending request held by the wrong template, and an actor with publish access to the shared reply queue can craft a message whose correlation identifier matches an in-flight request. The legitimate requester then either loses its reply to another consumer or accepts an attacker-supplied reply in its place. The direct reply-to mechanism, where RabbitMQ manages a per-channel pseudo-queue, does not rely on this application-generated tag in the same way; the predictable-identifier exposure is specific to the fixed reply queue configuration.

This vulnerability has been present since at least Spring AMQP 2.3 and likely earlier.

‍

Mitigation

Spring AMQP 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 correlation-identifier handling.

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.

‍