Kryo Configuration Allows Code Execution with Unknown "Serialization Gadgets"
- Published
- Last modified
- Where the record stands: published, rejected by its publisher, or superseded by another id.What do these mean? →
- published
- Whether CISA lists it in its Known Exploited Vulnerabilities catalog: proof that attackers are using it.What do these mean? →
- Not listed in CISA KEV
- Fix
- Fixed in v4.3.23.RELEASE, v5.1.12.RELEASE, v5.2.8.RELEASE, v5.3.2.RELEASE, 4.3.23, and 3 more
- Whether working attack code is public (Exploit-DB, Metasploit, Nuclei or GitHub). Public code makes attacks easier.What do these mean? →
- None on Exploit-DB, Metasploit or GitHub
Summary
Spring Integration framework provides Kryo Codec implementations as an alternative for Java (de)serialization. When Kryo is configured with default options, all unregistered classes are resolved on demand. This leads to the "deserialization gadgets" exploit when provided data contains malicious code for execution during deserialization. In order to protect against this type of attack, Kryo can be configured to require a set of trusted classes for (de)serialization. Spring Integration should be proactive against blocking unknown "deserialization gadgets" when configuring Kryo in code.
Timeline
- CVE published
- Record last updated
Affected versions
- Spring by VMware Spring Integration
From 4.3 · fixed in v4.3.23.RELEASE; From 5.1 · fixed in v5.1.12.RELEASE; From 5.2 · fixed in v5.2.8.RELEASE; From 5.3 · fixed in v5.3.2.RELEASE
- org.springframework.integration:spring-integration-coreMaven
From 4.3.0 · fixed in 4.3.23
- org.springframework.integration:spring-integration-coreMaven
From 5.3.0 · fixed in 5.3.2
- org.springframework.integration:spring-integration-coreMaven
From 5.1.0 · fixed in 5.1.12
- org.springframework.integration:spring-integration-coreMaven
From 5.2.0 · fixed in 5.2.8