Race Condition Affecting org.apache.kafka:kafka-clients package, versions [2.8.0,3.9.2)[4.0.0,4.0.2)[4.1.0,4.1.2)
Threat Intelligence
The probability is the direct output of the EPSS model, and conveys an overall sense of the threat of exploitation in the wild. The percentile measures the EPSS probability relative to all known EPSS scores. Note: This data is updated daily, relying on the latest available EPSS model version. Check out the EPSS documentation for more details.
Do your applications use this vulnerable package?
In a few clicks we can analyze your entire application and see what components are vulnerable in your application, and suggest you quick fixes.
Test your applications- Snyk IDSNYK-JAVA-ORGAPACHEKAFKA-16032179
- published14 Apr 2026
- disclosed7 Apr 2026
- creditBharath Vissapragada
Introduced: 7 Apr 2026
CVE-2026-35554 (opens in a new tab)How to fix?
Upgrade org.apache.kafka:kafka-clients to version 3.9.2, 4.0.2, 4.1.2 or higher.
Overview
org.apache.kafka:kafka-clients is a streaming platform that can publish and subscribe to streams of records, store streams of records in a fault-tolerant durable way, and process streams of records as they occur.
Affected versions of this package are vulnerable to Race Condition in Sender.sendProducerData, involving ByteBuffer reuse. An attacker can cause messages to be delivered to unintended topics by forcing the premature deallocation of a buffer via delivery.timeout.ms expiration, before the original network request completes, leaving it in the buffer pool. Consumers who have access to the destination topic but not the intended source topic may receive the deallocated buffer, without an error being emitted. The corrupted messages may themselves cause errors or deserialization failures.
The project maintainers note: "This bug has existed for more than a decade (since Kafka 0.x it seems), but never manifested because prior to 2.8.0 the pooled ByteBuffer (which contained record data aka your publishes) was copied into a freshly allocated ByteBuffer before any potential reuse and that fresh ByteBuffer was what got written over the network to the broker. With a change included in 2.8.0, the pooled ByteBuffer remains as-is inside of a MemoryRecords instance and this pooled ByteBuffer (which in some cases can be reused and overwritten with other data) is written over the network."