CVE-2026-47864 is unsafe Java deserialization in Spring Integration's SerializingHttpMessageConverter, scored CVSS 6.4 (medium) in the NVD record. Spring fixed it in 7.1.1 and 7.0.6 for open source users, with other lines through enterprise support. Upgrade, and set an allowlist if the converter handles untrusted input.
What's affected
The Spring advisory lists these affected Spring Integration versions:
- 7.1.0
- 7.0.0 through 7.0.5
- 6.5.0 through 6.5.10
- 6.4.0 through 6.4.12
- 5.5.21 and earlier
Fixed versions:
- 7.1.1 (open source) or 7.1.0.1 (Enterprise only)
- 7.0.6 (open source) or 7.0.5.1 (Enterprise only)
- 6.5.11 (Enterprise only)
- 6.4.13 (Enterprise only)
- 5.5.22 (Enterprise only)
The issue applies when an application uses SerializingHttpMessageConverter on an inbound HTTP endpoint. The NVD vector is CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:H/I:L/A:L, which reflects high complexity and a low privilege requirement. The advisory text itself describes a remote, unauthenticated attacker if a known gadget is on the classpath, so read the vector as a rating and the advisory as the description.
One detail matters a lot: the advisory says the fixed versions do not restrict deserialization unless allowed patterns are configured, to keep backward compatibility.
How to check if you're exposed
First, find the Spring Integration version.
Maven:
mvn dependency:tree -Dincludes=org.springframework.integration:spring-integration-http
Gradle:
gradle dependencies | grep spring-integration
Then search your own code for the converter and for endpoints that use it.
grep -rn "SerializingHttpMessageConverter" src/
If nothing uses the converter, the vulnerable path is not active in your code, though upgrading is still sensible. If something does, note which endpoints take requests from outside your network and what content types they accept.
The advisory says exploitation needs a deserialization gadget on the classpath. Your dependency list is where gadgets come from, so a software bill of materials helps you judge that part. Reachability analysis shows whether your code calls the converter at all.
What to do now
- Find every service that depends on Spring Integration HTTP support and note its version.
- Search the code for SerializingHttpMessageConverter and list the endpoints that use it.
- Upgrade to the fixed version for your line, or contact Spring about enterprise builds for older lines.
- Configure the allowlist with setAllowedPatterns or addAllowedPatterns so only the classes you expect can be read. Without patterns, the fixed versions keep the old behavior.
- Prefer a data format such as JSON for requests from outside your trust boundary, and avoid Java serialization where you can.
Why it matters
The weakness is CWE-502, deserialization of untrusted data. Java's object input stream rebuilds objects from bytes. When the bytes come from an outsider and no class filter applies, the outsider chooses which classes get built. If a class on the classpath does something harmful when constructed or used, it becomes a gadget. The advisory says the converter read bodies with a raw ObjectInputStream and no filtering.
The score is medium because the NVD vector assumes high complexity, but the outcome in the advisory is arbitrary code execution when a gadget is present. That makes your dependency tree part of the risk. The backward compatibility choice is also worth noting: upgrading alone may not close the exposure. The record's KEV flag is false.
Try it yourself
Click through it at your own pace, or open it full screen.
Quick check
Is CVE-2026-47864 exploited in the wild?
The record's KEV flag is false, and the pages I read do not say it is exploited. Treat it as a patch item and keep an eye on the advisory for changes.
Is upgrading enough?
Not on its own. The advisory says the fixed versions only restrict deserialization once you configure allowed patterns, so set an allowlist if the converter handles untrusted input.
Sources
Last reviewed: 19 October 2026.
