CVE-2026-59322

Overview

Spring Integration is the Spring portfolio project that brings the Enterprise Integration Patterns to Spring applications. It provides a lightweight messaging framework of channels, endpoints, transformers and routers, together with channel adapters for protocols and technologies such as files, FTP, HTTP, JDBC, JMS, AMQP, SMB and ZeroMQ. Several of those transports move a Message across the wire as a byte array, and a BytesMessageMapper is the component that converts between the two, deciding which of the message headers travel with the payload and which are reconstructed on arrival.

A resource injection vulnerability (CVE-2026-59322) has been identified in EmbeddedJsonHeadersMessageMapper in spring-integration-core, which allows attackers to place arbitrary entries into the MessageHeaders of an inbound message, including the control headers that decide which channel a reply or an error is routed to. The mapper's header pattern is applied only while encoding a message; on the decode path it deserializes the embedded JSON header map from the wire bytes and hands it to the new message without pattern matching, filtering or any reserved-name check, so the peer that produced the bytes decides the complete header set of the message that enters the flow. The weakness is classified as CWE-99, Improper Control of Resource Identifiers ('Resource Injection').

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.

The advisory rates this vulnerability Medium severity with the CVSS v3.1 vector AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:L/A:L, which corresponds to a base score of 6.3.

This issue affects Spring Integration >=5.0.0 <=5.4.13, >=5.5.0 <=5.5.20, >=6.0.0 <=6.1.9, >=6.2.0 <=6.2.11, >=6.3.0 <=6.3.11, >=6.4.0 <=6.4.10, >=6.5.0 <=6.5.10, >=7.0.0 <=7.0.5, and >=7.1.0 <=7.1.0, including the End-of-Life 5.5.x, 6.2.x, 6.3.x, 6.4.x, and 6.5.x lines supported by NES for Spring Integration.

Details

Module Info

• Product: Spring Integration
• Affected packages: org.springframework.integration:spring-integration-core
• Affected versions: >=5.0.0 <=5.4.13, >=5.5.0 <=5.5.20, >=6.0.0 <=6.1.9, >=6.2.0 <=6.2.11, >=6.3.0 <=6.3.11, >=6.4.0 <=6.4.10, >=6.5.0 <=6.5.10, >=7.0.0 <=7.0.5, >=7.1.0 <=7.1.0
• GitHub repository: https://github.com/spring-projects/spring-integration
• Published packages: https://central.sonatype.com/artifact/org.springframework.integration/spring-integration-core
• Package manager: Maven
• Fixed in:
  
  • NES for Spring Integration: 5.5.x, 6.2.x, 6.3.x, 6.4.x, 6.5.x
  • Spring Integration 7.0.6 and 7.1.1 (OSS)

Vulnerability Info

This Medium-severity vulnerability is found in the spring-integration-core package in multiple versions of Spring Integration. EmbeddedJsonHeadersMessageMapper converts between a Message and a byte array whose leading section carries the message headers as JSON. Its no-argument constructor, the one every default configuration uses, opts in to every header:

public EmbeddedJsonHeadersMessageMapper() {
        this("*");
}

That pattern is consulted only while encoding, where pruneHeaders drops the headers the pattern excludes. On the way back in, the mapper reads whatever header map is present in the incoming bytes and hands it straight to the new message:

@SuppressWarnings("unchecked")
Map<String, Object> headers = this.objectMapper.readValue(bytes, buffer.position(), headersLen,
                Map.class);
...
if (headersToAdd != null) {
        headersToAdd.forEach(headers::putIfAbsent);
}
return new GenericMessage<>(payload, new MutableMessageHeaders(headers));

No pattern matching, filtering or reserved-name check is applied on this path, so the peer that produced the bytes decides the complete header set of the message that enters the flow. MutableMessageHeaders accepts the map as given, including the framework's own control headers — replyChannel and errorChannel, which downstream handlers resolve by name through BeanFactoryChannelResolver, as well as routingSlip and the json__TypeId__ header that drives JSON type mapping.

The exposure is reachable with stock configuration because ZeroMqChannel, which arrives in the 5.4 line, installs this mapper by default and never narrows it:

private BytesMessageMapper messageMapper = new EmbeddedJsonHeadersMessageMapper();

An external peer can therefore steer a message into an internal channel that was never meant to be addressable from the network, or point error handling at a channel of its choice, simply by adding the corresponding header to the JSON section of the bytes it sends. Because the decode path ignores the header pattern entirely, constructing the mapper with a narrower pattern does not close the hole; the pattern constrains only what is written on the way out.

This vulnerability was introduced in 2017 with Spring Integration 5.0.0, although on the 5.0.x through 5.3.x lines it was reachable only through explicitly configured TCP or MQTT endpoints rather than with stock configuration.

Mitigation

Only recent versions of Spring Integration receive community support. The 5.5.x, 6.2.x, 6.3.x, 6.4.x, and 6.5.x lines are End-of-Life and will not receive public updates to address this issue, so there is no publicly available fix for those lines other than through a commercial support partner.

Applications that cannot upgrade immediately can reduce their exposure by making sure that no transport using this mapper is reachable by an untrusted peer, for example by restricting at the network layer which hosts may connect to a ZeroMqChannel, and by supplying their own BytesMessageMapper through setMessageMapper that discards the framework control headers after decoding rather than relying on the default. Narrowing the pattern passed to the EmbeddedJsonHeadersMessageMapper constructor is not a mitigation, because that pattern is applied only when headers are written. These steps limit who can reach the decode path and what survives it; they do not change the behaviour of the mapper itself, so upgrading remains the only complete fix.

Note that the fix deliberately changes a default: once it is applied, the mapper keeps only the standard framework headers from the wire, so an application that relied on the previous permissive default, for example one that round-trips its own custom headers over a ZeroMqChannel, will silently stop receiving those headers after upgrading and should declare the headers it needs as an explicit pattern. Declaring the pattern "*" is not such a configuration: a mapper constructed that way still accepts the complete header set supplied by the peer even after the fix, so an application that sets it stays exposed.

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

• Upgrade to a currently supported version of Spring Integration. The open-source fix ships in Spring Integration 7.0.6 on the 7.0.x line and 7.1.1 on the 7.1.x line.
• Leverage a commercial support partner like HeroDevs for post-EOL security support.