Description

SerializingHttpMessageConverter deserializes the body of incoming HTTP requests with a raw java.io.ObjectInputStream and no class filtering. Any request with Content-Type application/x-java-serialized-object whose body resolves to a Serializable type is read directly via readObject(). If an application using this converter on an inbound HTTP endpoint has any known Java deserialization "gadget" on its classpath, a remote, unauthenticated attacker can achieve arbitrary code execution. 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.4",
  "pubDate": "2026-08-27T06:17:17.017Z",
  "pubdate": "2026-08-27T06:17:17.017Z",
  "executiveSummary": "A critical insecure deserialization vulnerability exists within the SerializingHttpMessageConverter of Spring Integration. The vulnerability arises due to the application of java.io.ObjectInputStream on untrusted input without implementing any form of class filtering or validation.\nThis flaw allows a remote, unauthenticated attacker to execute arbitrary code on the host system. By sending a crafted HTTP request with the Content-Type header set to 'application/x-java-serialized-object', an attacker can supply a malicious serialized object that, when processed, triggers exploitation of gadget chains present on the application's classpath.\nThe impact of this vulnerability is total system compromise, potentially leading to unauthorized data access, service disruption, and persistent malware installation. The vulnerability affects multiple versions of Spring Integration across the 7.x, 6.x, and 5.x branches. Immediate remediation is required for any applications exposing HTTP endpoints that utilize this converter for deserialization tasks.",
  "technicalDetails": "The root cause of this vulnerability is the improper implementation of deserialization within the SerializingHttpMessageConverter component. Specifically, the converter invokes the readObject() method on a raw java.io.ObjectInputStream directly from the request body without enforcing an allow-list or performing any inspection of the serialized classes.\nThe vulnerability is triggered when the application environment includes common 'gadget' classes—existing library code that performs unintended operations during the instantiation or field-setting phase of deserialization. An attacker exploits this by crafting a serialized object payload that leverages these gadget chains. When the payload is processed by readObject(), the JVM recursively invokes methods defined in the gadget classes, which can be chained to execute arbitrary system commands, manipulate file systems, or exfiltrate sensitive data.\nThe attack flow proceeds as follows: 1) The attacker identifies an HTTP endpoint configured to use the vulnerable SerializingHttpMessageConverter. 2) The attacker crafts a malicious binary payload containing a serialized object graph designed to trigger a known gadget chain (e.g., using tools like Ysoserial). 3) The attacker sends an HTTP request to the target endpoint, explicitly setting the Content-Type header to 'application/x-java-serialized-object'. 4) The server-side converter reads the raw stream. 5) Upon calling readObject(), the JVM deserializes the payload, triggering the gadget chain and achieving Remote Code Execution (RCE) in the context of the application server.\nThis vulnerability is particularly dangerous as it does not require authentication, and the attack is delivered over the network. The scope of the vulnerability includes: 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, and Spring Integration 5.5.21 and earlier. Successful exploitation grants the attacker the same privileges as the user account running the Java application process, enabling full control over the application environment."
}