CVE-2026-47880 in Spring Integration
Summary
by MITRE • 08/27/2026
A producer who can publish to a JMS destination consumed by any Spring Integration JMS inbound component can set String JMS properties named replyChannel, errorChannel, or json__TypeId__ which are copied verbatim into the Spring Integration MessageHeaders. Spring Integration 7.1.0 Spring Integration 7.0.0 - 7.0.5 Spring Integration 6.5.0 - 6.5.10 Spring Integration 6.4.0 - 6.4.12 Spring Integration 5.5.21 and earlier
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 08/27/2026
The vulnerability described involves a critical security flaw within the Java Messaging Service integration capabilities of the Spring Framework, specifically affecting versions from 5.5.21 and earlier through to 7.0.5 and specific releases in the 6.x and 7.x branches such as 6.4.12, 6.5.10, and 7.1.0. This issue arises when a producer with permission to publish messages to a JMS destination that is consumed by any Spring Integration JMS inbound component can manipulate specific String-based JMS properties. The core technical flaw lies in the verbatim copying of these JMS properties directly into the internal Spring Integration MessageHeaders without adequate sanitization or validation, particularly for property names such as replyChannel, errorChannel, and json__TypeId__. This behavior creates a pathway for attackers to inject malicious data that is subsequently interpreted by the framework's messaging infrastructure.
From an operational perspective, this vulnerability allows for significant impact on application integrity and availability. By setting the replyChannel or errorChannel properties in JMS messages, an attacker can redirect message processing flows to unintended destinations or trigger specific error handling mechanisms that may lead to denial of service conditions through resource exhaustion or unexpected state changes. More critically, the manipulation of the json__TypeId__ property poses a severe risk related to object deserialization and type confusion. Since this property is copied verbatim into MessageHeaders, it can influence how JSON payloads are processed by underlying libraries like Jackson, potentially leading to insecure deserialization vulnerabilities if the framework attempts to instantiate classes based on these injected identifiers without proper allow-listing or validation.
This vulnerability aligns with CWE-94 Improper Control of Generation of Code (Code Injection) and CWE-502 Deserialization of Untrusted Data, as it involves injecting values that control internal behavior and potentially trigger unsafe object instantiation. In the context of the MITRE ATT&CK framework, this flaw facilitates techniques associated with T1190 Exploit Public-Facing Application and T1078 Valid Accounts if an attacker leverages legitimate credentials to publish malicious messages. The attack vector is remote if the JMS broker is accessible over a network, making it particularly dangerous in cloud-native or microservices architectures where message brokers are central communication hubs.
Mitigation strategies must focus on restricting access to JMS destinations and implementing strict validation of incoming message properties. Developers should ensure that only trusted producers can publish to sensitive queues or topics. Furthermore, configuration changes within Spring Integration components should be applied to disable the automatic copying of specific JMS headers into MessageHeaders unless explicitly required by business logic. Upgrading to a patched version of Spring Integration where this behavior is corrected or configurable with safer defaults is essential. Additionally, employing input validation frameworks and ensuring that deserialization processes use strict type allow-lists can further reduce the risk associated with any residual exposure until full patching is achieved.