CVE-2026-47880

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 Resource Injection vulnerability (CVE-2026-47880) has been identified in the DefaultJmsHeaderMapper component of Spring Integration, which allows message producers to set framework-significant header names such as replyChannel and errorChannel and so redirect handler output or error messages to any message channel bean in the application context.

‍

Per OWASP: This attack consists of changing resource identifiers used by an application in order to perform a malicious task. When an application defines a resource type or location based on user input, such as a file name or port number, this data can be manipulated to execute or access different resources.

‍

This issue affects the JMS inbound header mapping support of Spring Integration.

‍

Details

Module Info

• Product: Spring Integration
• Affected packages: org.springframework.integration:spring-integration-jms
• Affected versions: <= 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-jms
• 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-jms package in the JMS inbound header mapping support of Spring Integration.

‍

On the inbound path the mapper enumerated every user-defined JMS property on the incoming message and copied each one into the Spring Integration message headers under its own name:

Enumeration<?> jmsPropertyNames = jmsMessage.getPropertyNames();
if (jmsPropertyNames != null) {
    while (jmsPropertyNames.hasMoreElements()) {
        String propertyName = jmsPropertyNames.nextElement().toString();
        mapArbitraryProperty(jmsMessage, headers, propertyName);
    }
}

‍

private void mapArbitraryProperty(Message jmsMessage, Map<String, Object> headers, String propertyName) {
    try {
        String headerName = toHeaderName(propertyName);
        headers.put(headerName, jmsMessage.getObjectProperty(propertyName));
    }
    catch (Exception ex) {
        ...
    }
}

‍

Nothing distinguishes an application header from a header name the framework itself acts on. A producer able to publish to a consumed destination can therefore set string properties named replyChannel, errorChannel or json__TypeId__. Downstream framework code resolves a string reply or error channel header to a Spring bean through the bean-factory channel resolver, so the attacker selects which message channel bean receives handler output or error messages, bypassing the wiring the flow was designed with.

‍

This vulnerability was introduced in 2008 with Spring Integration 1.0.1.

‍

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.
• Leverage a commercial support partner like HeroDevs for post-EOL security support.