kafka-python EUVD-2026-36123

Attacker must be able to deliver bytes to the kafka-python client's TCP socket as if they were a Kafka broker response - either by operating a broker the victim bootstraps against, compromising a legitimate broker, or sitting on the network path of a non-TLS Kafka connection. No victim-side authentication, user interaction, or configuration changes are required; the vulnerable receive_bytes() path runs on every connection by default in all of KafkaConsumer, KafkaProducer, and KafkaAdminClient. Limiting factors: the attacker needs broker-position or MITM-position (not arbitrary internet reach), and impact is confined to availability of the kafka-python process - no code execution or data disclosure.

CVSS 4.0 8.7 is driven entirely by VA:H with VC:N/VI:N - this is a pure availability bug, not RCE or data exposure. AV:N/AC:L/AT:N/PR:N/UI:N is technically correct but materially misleading: exploitation requires the attacker to control or impersonate a Kafka broker the victim client connects to, which is not the same threat surface as a generic internet-exposed service. Realistic threat actors are malicious or compromised brokers in shared/multi-tenant Kafka deployments, or network-position attackers on unencrypted (non-TLS) Kafka traffic. No CISA KEV listing, no EPSS score provided, no public exploit identified at time of analysis. Priority should be moderate-to-high for shops running kafka-python consumers against untrusted or cross-tenant brokers (e.g., SaaS data pipelines), and lower for fully internal deployments with TLS and trusted broker fleets.

An attacker who controls a Kafka broker the victim client connects to (e.g., a malicious tenant in a shared cluster, a rogue insider, or a network attacker on plaintext Kafka traffic) sends a response frame whose 4-byte length prefix declares ~2 GB. The kafka-python parser attempts to allocate that buffer, exhausting victim process memory and triggering OOM-kill, or alternatively raises an uncaught ValueError that leaves the consumer's connection state broken and stops group heartbeats until the process is restarted. No public exploit identified at time of analysis, but the trigger is a one-packet condition trivially reproducible from any custom Kafka server stub.