Description

The EmbeddedHeadersJsonMessageMapper defaults to an overly permissive header parsing posture in its constructor. When decodeNativeFormat processes raw byte payloads, it deserializes embedded JSON headers into a plain Map and constructs a GenericMessage with MutableMessageHeaders without sanitizing or filtering untrusted header names by default. 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

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "6.3",
  "pubDate": "2026-08-27T20:17:58.263Z",
  "pubdate": "2026-08-27T20:17:58.263Z",
  "executiveSummary": "A vulnerability exists in the EmbeddedHeadersJsonMessageMapper component of Spring Integration, stemming from an overly permissive default posture regarding header parsing. When the system processes raw byte payloads via the decodeNativeFormat function, it deserializes embedded JSON headers directly into a Map structure.\nThis process creates GenericMessage objects utilizing MutableMessageHeaders without applying necessary sanitization or filtering to untrusted header names. The vulnerability allows an attacker to manipulate message metadata, potentially leading to unauthorized message routing, attribute injection, or disruption of downstream message processing logic.\nThe vulnerability affects Spring Integration versions 7.1.0, 7.0.0 - 7.0.5, 6.5.0 - 6.5.10, 6.4.0 - 6.4.12, and 5.5.21 and earlier. Exploitation allows an attacker to inject arbitrary headers into the message pipeline, circumventing intended security constraints applied at the application level. Given that these headers are processed in the context of the integration flow, the risk includes potential information disclosure or logic bypass if subsequent components rely on the integrity of message headers for security decisions or routing logic.\nNo specific authentication is required if the endpoint is exposed, as the payload processing occurs during the deserialization of the message transport layer.",
  "technicalDetails": "The root cause of this vulnerability lies in the constructor and the decodeNativeFormat function of the EmbeddedHeadersJsonMessageMapper class. By default, the mapper adopts an excessively permissive posture when interpreting incoming byte payloads that contain embedded JSON headers. During the deserialization phase, the mapper converts these JSON structures directly into a Map, which is then used to populate the MutableMessageHeaders of a GenericMessage object.\nThe technical failure occurs because there is a lack of an allow-list or filter mechanism to sanitize the header keys prior to object construction. Because MutableMessageHeaders allow for the modification of message attributes, an attacker can supply a malicious payload containing arbitrary or conflicting header keys within the JSON-encoded portion of the message. When the system processes this payload, it blindly trusts these headers, effectively injecting them into the message context.\nThe attack flow proceeds as follows: An attacker sends a crafted message payload to an integration endpoint that utilizes the vulnerable EmbeddedHeadersJsonMessageMapper. The decodeNativeFormat function is invoked to process the raw bytes. The mapper parses the JSON headers and maps them into the message metadata. Because no validation is performed, headers such as 'replyChannel', 'errorChannel', or other application-specific control headers can be overwritten or injected by the attacker. Subsequently, the message is passed to downstream components. If these components make security or routing decisions based on the presence or value of these manipulated headers, the attacker can influence the application flow, redirect traffic, or force error handling paths that may expose additional system information.\nThis vulnerability is particularly impactful because it exists at the infrastructure level of the integration flow. It does not require specific user privileges on the target system to trigger, provided the attacker can reach the input interface where the deserialization occurs. The lack of filtering on the header map allows for the mutation of message properties that are typically considered trusted metadata within the Spring Integration framework, potentially leading to sophisticated bypasses of downstream security filters that assume the integrity of the message headers."
}