CVE-2026-47864

Overview

Spring Integration extends the Spring programming model to support the well-known Enterprise Integration Patterns, providing message channels, endpoints, transformers, and channel adapters that let Spring applications exchange data with external systems over protocols such as HTTP, JMS, AMQP, TCP/UDP, syslog, and the file system.

A Remote Code Execution (RCE) vulnerability (CVE-2026-47864) has been identified in the SerializingHttpMessageConverter component of Spring Integration, which allows unauthenticated attackers to have arbitrary serialized Java objects read from an HTTP request body, and, where a suitable gadget class is on the classpath, to execute arbitrary code.

Per OWASP: Data which is untrusted cannot be trusted to be well formed. Malformed data or unexpected data could be used to abuse application logic, deny service, or execute arbitrary code, when deserialized.

This issue affects the HTTP message converter support of Spring Integration.

‍

Details

Module Info

• Product: Spring Integration
• Affected packages: org.springframework.integration:spring-integration-http
• Affected versions: >=1.0.2 <=5.5.21, >=6.0.0 <=6.4.12, >=6.5.0 <=6.5.10, >=7.0.0 <7.0.6, >=7.1.0 <7.1.1
• GitHub repository: https://github.com/spring-projects/spring-integration
• Published packages: https://central.sonatype.com/artifact/org.springframework.integration/spring-integration-http
• Package manager: Maven
• Fixed in:
  
  • NES for Spring Integration lines 5.5.x, 6.2.x, 6.3.x, 6.4.x and 6.5.x
  • OSS Spring Integration 7.0.6 and 7.1.1

Vulnerability Info

This Medium-severity vulnerability is found in the org.springframework.integration:spring-integration-http package in the HTTP message converter support of Spring Integration.

The converter accepts the application/x-java-serialized-object media type and reads the request body straight through a raw object input stream:

public class SerializingHttpMessageConverter extends AbstractHttpMessageConverter<Serializable> {

    private static final MediaType APPLICATION_JAVA_SERIALIZED_OBJECT =
            new MediaType("application", "x-java-serialized-object");
    ...
    @Override
    public Serializable readInternal(Class<? extends Serializable> clazz, HttpInputMessage inputMessage)
            throws IOException {

        try {
            return (Serializable) new ObjectInputStream(inputMessage.getBody()).readObject();
        }
        catch (ClassNotFoundException ex) {
            throw new IllegalArgumentException(ex);
        }
    }
    ...
}

There is no resolve-class hook, no allow-list and no type check before readObject() runs, so every class on the application classpath is reachable from the request body. On an inbound HTTP endpoint configured with this converter, a remote and unauthenticated request is therefore sufficient to drive object graph construction of the attacker's choosing, which is the standard precondition for gadget-chain code execution.

Note that the upstream change routes reads through an allow-list deserializing converter but keeps the previous unrestricted behavior when no patterns are configured. Applications that expose this converter to untrusted callers need to configure the allowed class and package patterns explicitly in order to benefit.

This vulnerability was introduced in 2009 with Spring Integration 1.0.2.

‍

Mitigation

Only recent versions of Spring Integration 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 Integration. Note that the upgrade does not change the default: the patched converter still deserializes any class until patterns are configured, so an application that exposes SerializingHttpMessageConverter to untrusted callers must also call setAllowedPatterns(...) on the converter, naming the class and package patterns it expects to receive.
• Leverage a commercial support partner like HeroDevs for post-EOL security support.

‍

Credits

• Uwez Khan (finder)
• Yu Bao from PayPal Cyber Security Team (finder)