CVE-2026-10142: kafka-python Denial-of-Service in Protocol Parser

Technical summary

The vulnerability exists in kafka-python's protocol parser, specifically in the receive_bytes() function, which fails to validate frame length values received from the broker. An attacker can craft a 4-byte frame length field with an arbitrarily large value, triggering one of two failure modes: (1) the parser attempts to allocate memory proportional to the specified length, exhausting available RAM, or (2) an unhandled ValueError is raised when processing the malformed frame, leaving the connection in a broken state. Once broken, the connection does not recover gracefully—pending requests hang indefinitely and consumer heartbeat intervals are skipped, preventing the broker from detecting client disconnect until a restart occurs.

Business impact

Production Kafka consumers using vulnerable kafka-python versions are at risk of unexpected service degradation or outages. An attacker with network access to the broker or capable of intercepting client-broker traffic can silently disable consumer groups, causing message processing delays or halts. The attack is particularly dangerous in scenarios where applications rely on automatic failover or where recovery requires manual intervention, since hung connections do not self-heal. Organizations processing time-sensitive data (financial transactions, IoT streams, event logs) face the most acute risk.

Affected systems

kafka-python library versions prior to 2.3.2 are affected. Any application or microservice that embeds kafka-python as a dependency is vulnerable if it connects to a Kafka broker. This includes Python-based consumer applications, data pipelines, and monitoring tools. Systems running kafka-python 2.3.2 or later are not vulnerable to this specific flaw.

Exploitability

Exploitability is high. The attack requires network access to the Kafka broker or the ability to intercept or redirect client-broker communications (man-in-the-middle position). No client authentication or complex setup is required; a single crafted message triggers the denial-of-service condition. However, the attacker must be positioned between the client and broker or control the broker itself—random internet attackers cannot exploit this remotely unless Kafka brokers are exposed on public networks. Internal network attackers and malicious or compromised brokers pose significant risk.

Remediation

Upgrade kafka-python to version 2.3.2 or later as soon as feasible. Verify the version in use by checking your Python environment and package manifest. If immediate patching is not possible, restrict network access to Kafka brokers to trusted clients only, and monitor for unexpected connection drops or hung consumer processes. Organizations should prioritize testing the upgrade in staging environments to ensure compatibility with application code and other Kafka configurations before production deployment.

Patch guidance

1. Identify all systems running kafka-python by reviewing requirements.txt, Pipfile, or package management tools (pip, poetry, conda). 2. Test kafka-python 2.3.2 in a non-production environment to verify no breaking changes affect your application. 3. Update the dependency specification in your build files to require kafka-python>=2.3.2. 4. Rebuild and redeploy consumer applications. 5. Verify consumer health by checking heartbeat logs and message processing metrics post-deployment. Consult the kafka-python release notes for any compatibility guidance specific to your version jump.

Detection guidance

Monitor for signs of exploitation: sudden spikes in memory usage on Kafka consumer processes, consumer group lag increasing without corresponding message volume increases, consumers failing heartbeat deadlines and being marked as dead, or connection errors in application logs with frame parsing exceptions. Correlate these signals across multiple consumer instances to identify coordinated attacks. Network detection can monitor for unusually large frame length values in Kafka protocol exchanges (frames claiming multi-gigabyte lengths are anomalous). Collect and analyze broker and client logs for ValueError exceptions during deserialization.

Why prioritize this

This vulnerability scores 7.5 (HIGH) on CVSS v3.1 because it enables network-accessible denial-of-service with no prerequisites. While it does not leak data or enable code execution, the ability to disable critical message processing infrastructure warrants swift remediation. The lack of KEV listing does not diminish urgency; internal threat modeling should assume sophisticated adversaries and supply-chain risks may accelerate exploitation. Organizations dependent on continuous Kafka processing should prioritize this patch within their change windows.

Risk score, explained

The CVSS 7.5 score reflects a network-reachable denial-of-service condition (AV:N, AC:L, PR:N) with high impact on availability (A:H) but no confidentiality or integrity impact (C:N, I:N). The absence of complexity requirements and the need for no special privileges make this a straightforward attack to execute from a network position. Scope is unchanged (S:U), meaning the impact is limited to the vulnerable Kafka client itself, not other systems—however, in systems where Kafka consumers are critical to business operations, this alone justifies high priority.

Frequently asked questions