CVE-2026-47860

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.

A Denial of Service (DoS) vulnerability (CVE-2026-47860) has been identified in the decompressing message post-processors of Spring AMQP, which allows attackers to publish a small compressed message whose expansion exhausts the consumer heap and terminates the application.

Per OWASP: The Denial of Service (DoS) attack is focused on making a resource (site, application, server) unavailable for the purpose it was designed. There are many ways to make a service unavailable for legitimate users by manipulating network packets, programming, logical, or resources handling vulnerabilities, among others.

This issue affects the message post-processor support of Spring AMQP.

‍

Details

Module Info

• Product: Spring AMQP
• Affected packages: org.springframework.amqp:spring-amqp
• Affected versions: >=1.4.2 <=2.4.18, >=3.0.0 <=3.2.12, >=4.0.0 <4.0.5, >=4.1.0 <4.1.1
• GitHub repository: https://github.com/spring-projects/spring-amqp
• Published packages: https://central.sonatype.com/artifact/org.springframework.amqp/spring-amqp
• Package manager: Maven
• Fixed in:
  
  • NES for Spring AMQP: 2.3.16-spring-amqp-2.3.21, 2.4.17-spring-amqp-2.4.28, 3.1.12-spring-amqp-3.1.20 and 3.2.12-spring-amqp-3.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-amqp package in the message post-processor support of Spring AMQP.

When an application enables decompression, either always or through the auto-decompress message property, the base post-processor streamed the whole decompressed body into an in-memory buffer with no ceiling on the result size:

@Override
public Message postProcessMessage(Message message) throws AmqpException {
    Object autoDecompress = message.getMessageProperties().getHeaders()
            .get(MessageProperties.SPRING_AUTO_DECOMPRESS);
    if (this.alwaysDecompress || (autoDecompress instanceof Boolean isAutoDecompress && isAutoDecompress)) {
        ByteArrayInputStream zipped = new ByteArrayInputStream(message.getBody());
        try {
            InputStream unzipper = getDecompressorStream(zipped);
            ByteArrayOutputStream out = new ByteArrayOutputStream();
            FileCopyUtils.copy(unzipper, out);
            MessageProperties messageProperties = message.getMessageProperties();
            ...
            return new Message(out.toByteArray(), messageProperties);
        }
        catch (IOException e) {
            throw new AmqpIOException(e);
        }
    }
    ...
}

FileCopyUtils.copy(unzipper, out) drains the decompressor until the stream ends, growing the ByteArrayOutputStream for as long as the payload expands. Because compression ratios for repetitive input are very high, a message of roughly a megabyte is enough to exhaust the heap of a consumer. The resulting OutOfMemoryError is handled by terminating the JVM, and redelivery of the same message on restart turns a single publish into a crash loop that persists until an operator purges the queue.

This vulnerability was introduced in 2014 with Spring AMQP 1.4.2.

‍

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.

The fix caps the decompressed body at 100 MB by default. That default is larger than the heap of a small container, so consumers running with less than roughly 240 MB of heap should also call setMaxDecompressedSize on the decompressing post-processor, with a limit of no more than about one third of the available heap.

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

• Upgrade to a currently supported version of Spring AMQP.
• Leverage a commercial support partner like HeroDevs for post-EOL security support.

‍

Credits

• Rong Sun (finder)