Java Deserialization vulnerability in Spring-Kafka When Improperly Configured
- 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 2.9.11, 3.0.10
- Whether working attack code is public (Exploit-DB, Metasploit, Nuclei or GitHub). Public code makes attacks easier.What do these mean? →
- 4 proofs of concept on GitHub
- Exploitation: none
- Automatable: no
- Technical impact: partial
Summary
In Spring for Apache Kafka 3.0.9 and earlier and versions 2.9.10 and earlier, a possible deserialization attack vector existed, but only if unusual configuration was applied. An attacker would have to construct a malicious serialized object in one of the deserialization exception record headers. Specifically, an application is vulnerable when all of the following are true: • The user does not configure an ErrorHandlingDeserializer for the key and/or value of the record • The user explicitly sets container properties checkDeserExWhenKeyNull and/or checkDeserExWhenValueNull container properties to true. • The user allows untrusted sources to publish to a Kafka topic By default, these properties are false, and the container only attempts to deserialize the headers if an ErrorHandlingDeserializer is configured. The ErrorHandlingDeserializer prevents the vulnerability by removing any such malicious headers before processing the record.
Timeline
- CVE published
- CISA SSVC assessment
Exploitation: none · Automatable: no · Technical impact: partial
- Record last updated
Affected versions
- Spring Spring For Apache Kafka
From 2.8.x · fixed in 2.9.11; From 2.9.x · fixed in 2.9.11; From 3.0.x · fixed in 3.0.10
- org.springframework.kafka:spring-kafkaMaven
From 2.8.1 · fixed in 2.9.11
- org.springframework.kafka:spring-kafkaMaven
From 3.0.0 · fixed in 3.0.10