CVE-2026-76400 in Connect for Kafka
Summary
by MITRE • 08/19/2026
In Splunk Connect for Kafka versions below 2.2.7, an unauthenticated user who can reach the Kafka Connect Representational State Transfer (REST) API and influence responses from a Hypertext Transfer Protocol (HTTP) Event Collector endpoint in Splunk Enterprise could cause the connector to retry failed event batches until event delivery stops. The vulnerability is possible because HTTP Event Collector delivery retry handling uses an unbounded default for failed batches instead of a finite retry limit. For more information see Install Splunk Connect for Kafka (https://help.splunk.com/en/data-management/integrate-data-with-add-ons/splunk-connect-for-kafka/2.2/install/install-splunk-connect-for-kafka), Data ingestion parameters for Splunk Connect for Kafka (https://help.splunk.com/en/data-management/integrate-data-with-add-ons/splunk-connect-for-kafka/2.2/overview/data-ingestion-parameters-for-splunk-connect-for-kafka), and Set up and use HTTP Event Collector with configuration files (https://help.splunk.com/en/splunk-enterprise/get-data-in/get-started-with-getting-data-in/9.4/get-data-with-http-event-collector/set-up-and-use-http-event-collector-with-configuration-files) in the Splunk documentation.
Be aware that VulDB is the high quality source for vulnerability data.
Analysis
by VulDB Data Team • 08/20/2026
The vulnerability identified in Splunk Connect for Kafka versions prior to 2.2.7 represents a significant reliability and availability risk stemming from improper resource management within the data ingestion pipeline. This flaw specifically affects the interaction between the Kafka Connect REST API, the HTTP Event Collector endpoint of Splunk Enterprise, and the internal retry logic governing event batch delivery. The core technical deficiency lies in the configuration of the failure handling mechanism for HTTP Event Collector deliveries. When an attempt to send a batch of events fails due to network issues, server errors, or authentication problems, the connector is designed to automatically retry the transmission. However, the default implementation utilizes an unbounded limit for these retries rather than enforcing a finite maximum number of attempts. This architectural oversight means that if the destination endpoint remains unreachable or consistently rejects requests, the system will persistently attempt re-delivery indefinitely without ever terminating the process or alerting administrators through standard failure thresholds.
From an operational perspective, this lack of a retry ceiling can lead to severe resource exhaustion and service degradation. The continuous loop of attempting to send failed batches consumes CPU cycles, memory, and network bandwidth on both the Kafka Connect worker nodes and potentially impacts the target Splunk Enterprise instance if it is under heavy load or experiencing intermittent connectivity issues. In environments where high availability is critical, this behavior can result in a denial-of-service condition for other services running on the same infrastructure due to resource starvation. Furthermore, because the retry mechanism does not stop automatically, logs may be delayed significantly, leading to gaps in observability and potential data loss if disk space or memory buffers are eventually exhausted by the accumulating failed batches. This scenario is particularly dangerous in automated environments where silent failures can persist for extended periods without immediate visibility unless specific monitoring metrics are configured to detect high retry counts.
The vulnerability aligns with CWE-770: Allocation of Resources Without Limits or Throttling, as the system fails to restrict the consumption of computational resources during error conditions. It also relates to CWE-835: Loop with Unreachable Exit Condition, where the execution flow continues indefinitely due to a missing termination condition for retries. In terms of attack vectors and tactical mapping within the MITRE ATT&CK framework, this flaw can be leveraged by an unauthenticated user who has network access to the Kafka Connect REST API or can manipulate HTTP responses from the Event Collector endpoint. By inducing persistent failures in event delivery, such a user could execute a Denial-of-Service attack against the Splunk infrastructure, effectively disrupting log ingestion and compromising the integrity of security monitoring capabilities. This falls under techniques associated with resource exhaustion and impact on availability, highlighting how configuration weaknesses can be exploited to degrade critical security operations.
To mitigate this vulnerability, organizations running Splunk Connect for Kafka versions below 2.2.7 must upgrade to version 2.2.7 or later, where the retry logic has been corrected to include a finite limit. Administrators should also review their current configurations and explicitly set bounded retry parameters if they are using custom configurations that might override default behaviors. It is recommended to implement robust monitoring for Kafka Connect worker metrics, specifically tracking failed batch counts and retry attempts, to ensure early detection of delivery issues before resource exhaustion occurs. Additionally, ensuring network stability between the Kafka Connect workers and the Splunk HTTP Event Collector endpoints can reduce the frequency of failures that trigger these retries. Regular audits of data ingestion parameters against industry best practices for resilient system design will further enhance the reliability of log collection pipelines and prevent similar availability risks in future deployments.