CVE-2026-59275

Overview

Spring AMQP is the Spring portfolio project that applies the core Spring programming model to AMQP messaging. It provides the message and template abstractions in the spring-amqp module, and the spring-rabbit module that implements them on top of the RabbitMQ Java client, including the listener containers that dispatch inbound messages to application listeners.

A Denial of Service (DoS) vulnerability (CVE-2026-59275) has been identified in the allow-list check used by the Java serialization message converters, which allows an attacker who can publish a message to a consumed queue to terminate the entire consumer JVM rather than only the listener thread.

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 Java serialization support and the RabbitMQ listener containers of Spring AMQP.

‍

Details

Module Info

• Product: Spring AMQP
• Affected packages:
  
  • org.springframework.amqp:spring-amqp
  • org.springframework.amqp:spring-rabbit
• Affected versions:
  
  • org.springframework.amqp:spring-amqp: >=4.1.0 <4.1.1, >=4.0.0 <4.0.5, >=2.1.0 <=3.2.12
  • org.springframework.amqp:spring-rabbit: >=4.1.0 <4.1.1, >=4.0.0 <4.0.5, >=2.1.0 <=3.2.12
• 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.x, 2.4.x, 3.1.x, 3.2.x
  • OSS Spring AMQP 4.0.5, 4.1.1

Vulnerability Info

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

SerializationUtils.checkAllowedList() is the single gate that the Java serialization converters, such as SimpleMessageConverter, apply to every class read from an inbound message body. The check returns immediately for any array class:

public static void checkAllowedList(Class<?> clazz, Set<String> patterns) {
        if (TRUST_ALL && ObjectUtils.isEmpty(patterns)) {
                return;
        }
        if (clazz.isArray() || clazz.isPrimitive() || Number.class.isAssignableFrom(clazz)
                        || String.class.equals(clazz)) {
                return;
        }
        String className = clazz.getName();
        for (String pattern : patterns) {
                if (PatternMatchUtils.simpleMatch(pattern, className)) {
                        return;
                }
        }
        throw new SecurityException("Attempt to deserialize unauthorized " + clazz
                        + "; add allowed class name patterns to the message converter or, if you trust the message originator, "
                        + "set environment variable '"
                        + TRUST_ALL_ENV + "' or system property '" + TRUST_ALL_PROP + "' to true");
}

Because clazz.isArray() short-circuits the whole check, the component type is never examined, so a hostile publisher can send a serialized payload whose declared type is a deeply nested array such as Object[][][]...[] and have it accepted no matter which allow-list patterns the application configured. Resolving a type descriptor of that shape recurses until the consumer thread exhausts its stack, and the resulting StackOverflowError propagates out of the listener into the container, where the default handler treats every java.lang.Error identically:

private JavaLangErrorHandler javaLangErrorHandler = error -> System.exit(EXIT_99);

A single hostile message therefore ends the process with exit code 99, taking down every other workload that shares the JVM, not just the listener that received the message.

This vulnerability was introduced in Spring AMQP 2.1.0.

‍

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:

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