CVE-2026-10142: kafka-python DOS Vulnerability

CVE-2026-10142 Overview

CVE-2026-10142 is a denial-of-service vulnerability in kafka-python versions prior to 2.3.2. The flaw resides in the protocol parser, which fails to validate a 4-byte frame length value received from the network. A malicious broker or machine-in-the-middle (MITM) attacker can send a crafted frame length through the receive_bytes() function. This triggers either a multi-gigabyte memory allocation or an uncaught ValueError that leaves the connection in a broken state. The result is hung requests and consumers that stop heartbeating until they are restarted. The weakness is classified as [CWE-789] Memory Allocation with Excessive Size Value.

Critical Impact
Network-positioned attackers can exhaust client memory or stall Kafka consumers without authentication, disrupting data pipelines that depend on kafka-python.

Affected Products

kafka-python versions prior to 2.3.2
Applications embedding the kafka-python client library for Apache Kafka connectivity
Python-based consumers and producers communicating with Kafka brokers over untrusted networks

Discovery Timeline

2026-06-10 - CVE-2026-10142 published to the National Vulnerability Database (NVD)
2026-06-10 - Last updated in NVD database

Technical Details for CVE-2026-10142

Vulnerability Analysis

The vulnerability stems from how kafka-python parses inbound Kafka wire-protocol frames. Each frame begins with a 4-byte length prefix that tells the client how many bytes to read next. The parser interprets this value without bounds validation before calling receive_bytes() to allocate and read the indicated buffer.

When an attacker supplies an oversized length value, the client attempts to allocate multi-gigabyte buffers, exhausting host memory. When an attacker supplies a malformed value that triggers a ValueError in downstream decoding, the exception is not caught at the I/O layer. The connection is left in a partially-read, broken state. Subsequent requests block indefinitely, and consumer group members stop sending heartbeats. The broker then evicts them from the group, halting message processing until operators restart the affected process.

Root Cause

The protocol parser trusts the network-supplied frame length without sanity-checking it against the maximum legitimate Kafka message size or available client memory. There is no upper bound enforced before allocation, and exceptions raised during frame decoding are not handled in a way that preserves connection consistency.

Attack Vector

Exploitation requires the attacker to control or intercept the byte stream the client receives. Two scenarios apply: a malicious or compromised Kafka broker that the client connects to, or a machine-in-the-middle attacker on an unencrypted or improperly authenticated TLS channel. No authentication to the client is required, and no user interaction is involved.

python

# Patch excerpt from commit 6e4831444f972d169cdd11f5c8d50333cea3f19b
# kafka/sasl/scram.py - Validate SASL/SCRAM iterations (#3026)
# Companion hardening shipped with the protocol parser fix in 2.3.2

        self.auth_message += b',c=biws,r=' + self.nonce

        salt = base64.b64decode(params['s'].encode('utf-8'))
-       iterations = int(params['i'])
+       try:
+           iterations = int(params['i'])
+           if iterations > 1000000:
+               raise ValueError('too many iterations')
+       except (TypeError, ValueError):
+           raise ValueError('Invalid value (not integer or too large) for Iteration count in server-first-message')
        self.create_salted_password(salt, iterations)

        self.client_key = self.hmac(self.salted_password, b'Client Key')

Source: GitHub commit 6e48314. This patch shows the same defensive pattern applied across the 2.3.2 hardening effort: validate untrusted integers from the wire and convert silent failures into explicit, bounded errors.

Detection Methods for CVE-2026-10142

Indicators of Compromise

Python processes using kafka-python showing sudden, unexplained memory growth into the multi-gigabyte range
Kafka consumers repeatedly evicted from consumer groups due to missed heartbeats
Application logs containing uncaught ValueError exceptions originating in kafka.protocol or receive_bytes()
TCP sessions to Kafka brokers stalled with large pending read buffers

Detection Strategies

Inventory deployed Python applications and identify those importing kafka or kafka-python at version < 2.3.2
Monitor process resident set size (RSS) for Kafka client workers and alert on rapid growth inconsistent with message throughput
Parse application logs for unhandled exceptions in the kafka-python call stack, particularly in protocol decoding paths

Monitoring Recommendations

Track consumer group rebalance frequency and heartbeat failures via Kafka broker metrics
Alert when consumer lag grows while no corresponding broker-side issues are present, indicating a stalled client
Capture network telemetry on broker-to-client connections to identify anomalous frame length values when feasible

How to Mitigate CVE-2026-10142

Immediate Actions Required

Upgrade kafka-python to version 2.3.2 or later across all producers, consumers, and admin tooling
Audit dependency manifests (requirements.txt, Pipfile.lock, poetry.lock) for transitive pins to vulnerable versions
Restart any long-running Kafka client processes after upgrade to ensure the patched code is loaded

Patch Information

The fix is delivered in kafka-python2.3.2. The protocol parser now validates frame length values before allocation, and decoding exceptions are handled so the connection state remains consistent. Review the VulnCheck Advisory for kafka-python, GitHub Pull Request #3019, and GitHub Pull Request #3026 for the full set of changes.

Workarounds

Enforce mutual TLS (mTLS) between clients and brokers to prevent machine-in-the-middle injection of crafted frames
Restrict outbound connectivity from Kafka clients to a known, trusted broker allowlist
Apply process-level memory limits (for example, cgroupsmemory.max or container memory caps) so a triggered allocation fails fast rather than exhausting the host
Implement supervisor-based auto-restart for consumer processes to recover from hung connections until the upgrade is deployed

bash

# Configuration example: upgrade and pin kafka-python to a fixed version
pip install --upgrade 'kafka-python>=2.3.2'

# Verify the installed version
python -c "import kafka; print(kafka.__version__)"

# Example systemd hardening for a consumer service
# /etc/systemd/system/kafka-consumer.service
# [Service]
# MemoryMax=2G
# Restart=on-failure
# RestartSec=5s