CVE-2026-10143: kafka-python SCRAM DoS – Event Loop Freeze Vulnerability

Technical summary

The vulnerability exists in kafka-python's SCRAM authentication implementation, specifically in scram.py within the ScramClient.process_server_first_message() method. The flaw stems from insufficient input validation on the iteration count parameter received from a broker during the SCRAM handshake. This untrusted value is passed directly to hashlib.pbkdf2_hmac(), which performs CPU-intensive key derivation. When an attacker supplies an excessively large iteration count (e.g., billions of iterations), the PBKDF2 operation consumes the event loop for an extended period, effectively blocking the entire client. The event loop freeze impacts all concurrent operations: producer sends are blocked, consumer polls timeout, admin API calls hang, and heartbeat timers expire. In group-aware consumer scenarios, expired heartbeats trigger rebalancing logic that evicts the client from its consumer group. Subsequent reconnection attempts repeat the authentication freeze, creating a persistent denial-of-service condition. The vulnerability is classified under CWE-400 (Uncontrolled Resource Consumption) and CWE-606 (Unchecked Input for Loop Condition).

Business impact

This vulnerability can cause significant operational disruption for organizations using kafka-python. Applications experience sudden inability to read or write Kafka messages without explicit error messages in many cases—the freeze appears as a hang. Consumer applications are silently evicted from groups, losing their assigned partitions and processing state, requiring manual intervention to recover. In streaming data pipelines, event-driven architectures, and real-time analytics platforms, such outages translate directly to data loss or delayed insights. For financial services, logistics, or monitoring systems where Kafka carries critical data, a prolonged freeze can cascade into downstream failures. The attack surface is particularly broad because any network path to the Kafka broker—whether direct or through a proxy—could be exploited, including compromised infrastructure or network segments.

Affected systems

kafka-python prior to version 2.3.2 is affected. The dpkp/kafka-python library is widely used in Python environments for Kafka connectivity, including in Django applications, microservices, data pipelines, and monitoring tools. Any system running an affected version and authenticating to Kafka using SCRAM (Simple Authentication and Security Mechanism) is vulnerable. This includes both SCRAM-SHA-256 and SCRAM-SHA-512 variants, as both use the same vulnerable code path. Systems not using SCRAM authentication (e.g., using plaintext, SSL certificates, or other mechanisms) are not affected by this specific flaw.

Exploitability

Exploitation requires network-level access to the Kafka broker or the ability to intercept client-broker communication. An attacker can be either a malicious Kafka broker instance or a man-in-the-middle positioned on the network path. No client-side user interaction is required; the attack triggers automatically during the SCRAM authentication phase when a client connects. The attack is deterministic and reliable—a sufficiently large iteration count will consistently freeze the client. The CVSS 3.1 score of 7.5 (HIGH) reflects the high availability impact and low attack complexity, though the attack requires network proximity and does not compromise confidentiality or integrity. The vulnerability is not currently tracked in CISA's Known Exploited Vulnerabilities (KEV) catalog, suggesting active exploitation in the wild has not been formally documented, though proactive patching remains essential given the straightforward exploitation mechanism.

Remediation

The primary remediation is to upgrade kafka-python to version 2.3.2 or later. This version implements validation on the SCRAM iteration count, rejecting excessively large values and preventing the event loop freeze. In addition to patching, organizations should review their SCRAM broker configurations and ensure brokers are hardened against unauthorized access or replacement. Network segmentation and monitoring of broker traffic for anomalous iteration counts can provide defense-in-depth. For systems unable to patch immediately, switching to alternative authentication mechanisms (TLS client certificates, plaintext with network isolation, or OAuth2 where supported) can reduce exposure, though this requires architectural changes.

Patch guidance

Verify your current kafka-python version using `pip show kafka-python` or checking your application's requirements.txt or setup.py. If the version is below 2.3.2, update to 2.3.2 or the latest stable release available from the official dpkp/kafka-python GitHub repository or PyPI. For production environments, test the upgrade in a staging environment first to ensure compatibility with your Python version (verify supported Python versions in the release notes). Restart all affected client applications after upgrading to ensure the new library code is loaded. If you are using a vendored or pinned version, update your dependency manifest and rebuild container images or deployment artifacts. Monitor reconnection behavior for a brief period post-upgrade to confirm normal operation.

Detection guidance

Monitor client-side logs for repeated authentication failures or extended delays during the SCRAM handshake phase. Event loop stalls typically manifest as timeouts or hung producer/consumer operations without explicit socket errors. On the broker side, enable audit logging if available and watch for SCRAM authentication requests with unusually large iteration count values (normal values are typically in the range of 4096 to 15000). Network-level detection can identify SCRAM frames with anomalous iteration counts; this would require inspection of the SCRAM protocol exchange. Evaluate your current version inventory using software composition analysis tools or package scanning to identify affected deployments. Set up alerts on library update failures or version drift to catch instances where patches are not applied uniformly across environments.

Why prioritize this

This vulnerability merits prioritization due to its HIGH CVSS score, straightforward exploitability, and potential for operational disruption. While it does not directly expose data or allow unauthorized access, it can disable critical data pipelines and cause consumer group failures that require manual recovery. Organizations running Kafka-centric architectures should prioritize patching. However, those not using SCRAM authentication or running Kafka outside the network perimeter can adjust priority downward. The absence of active public exploitation (KEV status: false) provides a short window for proactive patching before adversaries widely adopt the technique.

Risk score, explained

The CVSS 3.1 score of 7.5 reflects: (1) Network-accessible attack vector with no prerequisites (AV:N, PR:N, UI:N), (2) low attack complexity due to straightforward iteration count manipulation, (3) high availability impact from event loop freezing, and (4) no confidentiality or integrity compromise. The score appropriately captures the denial-of-service severity while acknowledging the scope limitation to the affected client. For organizations where Kafka availability is critical to operations, the business risk may warrant treating this as a 'Critical' priority despite the CVSS 'HIGH' rating.

Frequently asked questions