Vulnerability Directory | CVE-2023-34050 | Spring

Overview

Spring AMQP is the Advanced Message Queuing Protocol (AMQP) support project of the Spring ecosystem. It provides template abstractions, listener containers, and message converters used to integrate Spring applications with AMQP-compatible brokers such as RabbitMQ. Converting between a wire-level AMQP message payload and a Java object is the responsibility of a MessageConverter. Two built-in converters, SimpleMessageConverter and SerializerMessageConverter, fall back to standard Java serialization (ObjectInputStream) when the incoming message is marked with the application/x-java-serialized-object content type.

A medium-severity vulnerability (CVE-2023-34050) has been identified in how those converters validate the classes they are willing to deserialize. An "allowed list" mechanism exists to restrict deserialization to a configured set of class name patterns, but in affected versions the list is empty by default, and the validation helper treats an empty list as "trust everything" rather than "trust nothing." An attacker who can publish messages to an AMQP queue consumed by the application can therefore send a crafted serialized Java payload that, in combination with deserialization gadgets already present on the application classpath, leads to arbitrary class instantiation and remote code execution.

Per OWASP: "Data which is untrusted cannot be trusted to be well formed." Deserializing untrusted data without a class allow-list is a textbook instance of CWE-502 (Deserialization of Untrusted Data) and has been the root cause of numerous high-impact remote code execution vulnerabilities in the Java ecosystem.

The CVSS v3.1 base score for this vulnerability is 5.3 (Medium) per the VMware CNA scoring. Exploitation requires the attacker to be able to publish messages to an AMQP destination the application is consuming from, which is typically constrained to authenticated broker clients but is routinely exposed to untrusted senders in multi-tenant or internet-facing deployments.

This issue affects Spring AMQP versions 1.0.0 through 2.4.16, and 3.0.0 through 3.0.9.

‍

Details

Module Info

Product: Spring AMQP
Affected packages: spring-amqp, spring-rabbit
Affected versions: >=1.0.0 <=2.4.16, >=3.0.0 <=3.0.9
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
- Spring AMQP 2.4.17 (OSS), 3.0.10 (OSS)

Vulnerability Info

When Spring AMQP receives a message whose content type is application/x-java-serialized-object, the default SimpleMessageConverter delegates to SerializationUtils.deserialize(InputStream, Set<String>, ClassLoader). That method wraps the stream in a ConfigurableObjectInputStream whose resolveClass(ObjectStreamClass) callback checks the resolved class against the configured allowed-list patterns:

public static void checkAllowedList(Class<?> clazz, Set<String> patterns) {
    if (ObjectUtils.isEmpty(patterns)) {
        return;
    }
    if (clazz.isArray() || clazz.isPrimitive() || clazz.equals(String.class)
            || Number.class.isAssignableFrom(clazz)) {
        return;
    }
    String className = clazz.getName();
    for (String pattern : patterns) {
        if (PatternMatchUtils.simpleMatch(pattern, className)) {
            return;
        }
    }
    throw new SecurityException("Attempt to deserialize unauthorized " + clazz);
}

‍

The first two lines make the allow-list "opt-in" rather than "opt-out": if the consuming application never calls setAllowedListPatterns(...) on its converter, patterns is empty, the method returns immediately, and resolveClass is free to load any class on the application classpath. Combined with deserialization gadget chains that are reachable on a typical Spring Boot application (transitive dependencies such as Commons-Collections, Spring's own AspectJWeaver and TemplatesImpl gadgets, and others), this yields remote code execution against the AMQP consumer.

The fix introduces an explicit "trust all" flag that operators must set deliberately. An empty pattern set is now treated as "deny all classes" by default:

private static final String TRUST_ALL_ENV = "SPRING_AMQP_DESERIALIZATION_TRUST_ALL";
private static final String TRUST_ALL_PROP = "spring.amqp.deserialization.trust.all";
private static final boolean TRUST_ALL;

static {
    TRUST_ALL = Boolean.parseBoolean(System.getenv(TRUST_ALL_ENV))
            || Boolean.parseBoolean(System.getProperty(TRUST_ALL_PROP));
}

public static void checkAllowedList(Class<?> clazz, Set<String> patterns) {
    if (TRUST_ALL && ObjectUtils.isEmpty(patterns)) {
        return;
    }
    ...
    throw new SecurityException("Attempt to deserialize unauthorized " + clazz
            + "; add allowed class name patterns to the message converter or, if you trust "
            + "the message orginiator, set environment variable '"
            + TRUST_ALL_ENV + "' or system property '" + TRUST_ALL_PROP + "' to true");
}

‍

The new SecurityException message also guides operators to configure an explicit allow-list rather than re-enabling the legacy behavior.

‍

Mitigation

Only recent versions of Spring AMQP receive community support and updates. Older versions have no publicly available fixes for this vulnerability.

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 through Never-Ending Support (NES) for Spring AMQP.

As a configuration-only workaround for operators who cannot upgrade immediately, call setAllowedListPatterns(...) on every SimpleMessageConverter or SerializerMessageConverter instance the application exposes, passing a list of class name patterns that covers only the message payload types the application actually expects to receive. Avoid setting the SPRING_AMQP_DESERIALIZATION_TRUST_ALL environment variable or the spring.amqp.deserialization.trust.all system property introduced in the patched versions, as doing so restores the vulnerable "trust everything" behavior.

‍