CVE-2026-35554

What it actually does

This is a race condition in the Apache Kafka Java producer client buffer pool. Under specific timing conditions, a producer batch can expire because delivery.timeout.ms is reached while the network request carrying that batch is still in flight. The batch ByteBuffer may then be returned to the reusable buffer pool too early. If another produce batch reuses that buffer before the original network send completes, the in-flight request can be corrupted with data intended for another topic. The result is silent misdelivery: records intended for one topic may be written to a different topic without the producer receiving an error. The primary impacts are confidentiality loss, because data may appear in a topic whose consumers should not see it, and integrity loss, because downstream consumers may process unexpected or schema-incompatible records.

Why it matters to the business

Organizations using affected Kafka Java producer clients may experience silent data leakage between topics and downstream data corruption. This can expose sensitive business, customer, operational, or regulated data to unintended consumers and can also break analytics pipelines, event-driven workflows, reconciliation jobs, fraud detection, billing, or compliance reporting that depend on topic correctness. The CVSS score is high, but exploitation requires a narrow race condition and current public exploitation signals are low: EPSS is approximately 0.0033 with no 30-day increase, it is not listed in CISA KEV, and no exploit maturity is reported. However, because Kafka clients are often embedded across many services, the operational blast radius may be broad if multiple applications depend on vulnerable kafka-clients versions.

How an attack unfolds

An attacker or fault-inducing actor would need to create or take advantage of conditions where Kafka Java producers experience delayed in-flight produce requests and batch expiration. This could involve network latency, broker slowness, throttling, overload, or producer timeout settings that allow delivery.timeout.ms to expire while a request is still being transmitted or awaiting completion. Once the original batch expires, the vulnerable producer client may prematurely release its ByteBuffer back to the buffer pool. A later batch, possibly for a different topic, can reuse that same buffer before the original send finishes. The original network request may then carry corrupted or replaced contents, causing Kafka to write messages to an unintended topic. The producer may not report a send failure, making exploitation or accidental triggering difficult to observe directly. No named threat actor activity or known ransomware use is currently associated with this issue.

How to fix it

Upgrade all applications and services that include the Apache Kafka Java producer client to a fixed version. Fixed versions are Apache Kafka 3.9.2, 4.0.2, 4.1.2, 4.2.0, or later. Because the flaw is in the Java producer client, remediation must cover application dependencies, shaded JARs, container images, build artifacts, stream-processing jobs, connectors, and any internally packaged libraries that bundle kafka-clients. If immediate upgrade is not possible, reduce risk by avoiding aggressive delivery.timeout.ms values, investigating producer timeouts, improving broker/network stability, reducing overload or throttling, and separating high-sensitivity data flows from lower-trust topics. These mitigations reduce the likelihood of the race but should not be treated as complete fixes.

How to confirm the fix worked

Confirm the effective kafka-clients library version used at runtime, not only the declared top-level Kafka version. Inspect dependency manifests, SBOMs, application startup logs, container layers, Gradle/Maven dependency trees, and packaged JAR contents for org.apache.kafka:kafka-clients. Validate that all producer applications use 3.9.2, 4.0.2, 4.1.2, 4.2.0, or later. After upgrade, run a controlled producer test under latency and timeout stress and verify that expired batches do not result in records appearing in unintended topics. Monitor producer logs and metrics for delivery timeouts, record errors, retries, and buffer pool pressure. Also validate data-plane correctness by checking topic schemas, message headers, lineage metadata, and consumer deserialization errors for signs of cross-topic contamination.

Typical attack path

1. Identify applications using affected Apache Kafka Java producer client versions: 3.9.1 or earlier, 4.0.1 or earlier, or 4.1.1 or earlier.
2. Create or wait for producer conditions with high latency, broker throttling, network delay, overload, or aggressive delivery.timeout.ms settings.
3. Cause a produce batch to exceed delivery.timeout.ms while its network request remains in flight.
4. Rely on the vulnerable client returning the expired batch ByteBuffer to the producer buffer pool before the in-flight request is complete.
5. Trigger additional produce traffic, potentially to a different topic, so the freed buffer is reused.
6. The in-flight request becomes corrupted or overwritten and Kafka accepts records under an unintended topic.
7. Consumers of the unintended topic receive unexpected data, causing possible data exposure, deserialization failures, or downstream processing corruption.

How to detect it

There is no reliable single indicator proving malicious exploitation because the failure mode can look like ordinary timeout, latency, or data quality issues. Investigate both producer-side and consumer-side evidence. On producer hosts and application logs, look for delivery timeouts, expired batches, repeated retries, request latency spikes, broker throttling, and buffer pool pressure near the time unexpected records appeared. In Kafka broker logs and metrics, correlate produce request latency, request queue time, network processor saturation, throttling, and abnormal produce traffic. On consumers, search for deserialization failures, schema registry incompatibility errors, unexpected event types, unexpected producer identifiers, malformed payloads, or records whose headers, keys, schemas, or business identifiers do not match the destination topic. For forensic review, compare producer application logs or audit trails showing intended topic names against broker topic offsets and consumer observations. Treat clusters of producer TimeoutException events followed by unexpected records in unrelated topics as high-value leads.

• org.apache.kafka.common.errors.TimeoutException: Expiring
• ms has passed since batch creation
• delivery.timeout.ms
• record(s) for
• org.apache.kafka.clients.producer.internals.Sender
• org.apache.kafka.clients.producer.internals.RecordAccumulator
• RecordDeserializationException
• SerializationException: Error deserializing
• Error deserializing key/value for partition
• Unknown magic byte
• Schema not found
• Subject not found
• bufferpool-wait-time-total
• bufferpool-wait-ratio
• record-error-rate
• record-retry-rate
• request-latency-avg
• produce-throttle-time-avg

What your security team should do

• Prioritize inventory of all applications, stream processors, connectors, and services that produce to Kafka using the Java kafka-clients library.
• Upgrade affected clients to Apache Kafka 3.9.2, 4.0.2, 4.1.2, 4.2.0, or later, focusing first on producers handling sensitive, regulated, financial, authentication, or operationally critical data.
• Do not rely on broker-only patching; verify the producer client dependency embedded in each application artifact.
• Search historical logs for producer batch expirations, delivery timeouts, deserialization failures, schema violations, and unexpected message types in topics.
• Temporarily tune producer timeout settings and address network or broker latency issues where immediate upgrade cannot be completed.
• Review topic access controls and consumer permissions to limit the impact if records are misdelivered.
• Add data validation controls such as schema enforcement, topic-specific message headers, producer identity metadata, and dead-letter handling for unexpected payloads.
• Because this is not currently KEV-listed and EPSS remains low, prioritize based on data sensitivity and Kafka producer prevalence rather than public exploit activity alone.