Spring-Kafka has Java Deserialization vulnerability When Improperly ConfiguredGHSA-crqf-q9fp-hwjw
HIGHFix: spring-projects/spring-kafka@25ac793GHSA-crqf-q9fp-hwjw is a high-severity (CVSS 7.8) Deserialization of Untrusted Data vulnerability in org.springframework.kafka:spring-kafka. 4 public exploit or proof-of-concept references are indexed, so weaponization risk is real. A fix is available for org.springframework.kafka:spring-kafka — see the affected versions and patch details below.
Exploitation Status
No confirmed exploitation observed yet
- CISA’s own triage has not observed active exploitation or public proof-of-concept code for this CVE as of its last assessment.
Exploitation and automatability from CISA’s SSVC triage for GHSA-crqf-q9fp-hwjw.
EPSS Exploitation Probability
Probability of exploitation in the next 30 days, from FIRST.org EPSS.
How urgent is this, really
Where this sits among everything scored
Real-World Exposure
org.springframework.kafka:spring-kafka☕org.springframework.kafka:spring-kafkaReal-time download stats are indexed for npm and PyPI packages. This vulnerability affects Maven packages — download data is not available via public APIs for these ecosystems.
Description
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.
Affected Packages
| Ecosystem | Package | Vulnerable range | Fix |
|---|---|---|---|
| ☕Maven | org.springframework.kafka:spring-kafka | ≥ 2.8.1&&< 2.9.11 | 2.9.11org.springframework.kafka:spring-kafka:2.9.11 |
| ☕Maven | org.springframework.kafka:spring-kafka | ≥ 3.0.0&&< 3.0.10 | 3.0.10org.springframework.kafka:spring-kafka:3.0.10 |
Affected Products
spring for apache kafkavmwareResearch use only. For defensive security, authorized penetration testing, and academic research only. Never execute exploit code against systems without explicit written authorization.
Detection & mitigation playbook
Open-source dependencyDetect
Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for org.springframework.kafka:spring-kafka, including transitive dependencies — a direct dependency you never call can still pull in a vulnerable version.
Fix
Update org.springframework.kafka:spring-kafka to 2.9.11 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-crqf-q9fp-hwjw is resolved across your whole dependency graph.
Workarounds
Do not deserialise data from untrusted sources: where the format allows it, restrict deserialisation to an explicit allowlist of expected types, and prefer a data-only format (JSON, Protobuf) over one that can reconstruct arbitrary objects until you can upgrade.
Frequently Asked Questions
Is GHSA-crqf-q9fp-hwjw in your dependencies?
Find it across Maven, including transitive dependencies.