Splunk Connect for Kafka EUVD-2026-62965

Exploitation requires two simultaneous conditions to be satisfied. First, the attacker must have network-level access to the Kafka Connect REST API endpoint (typically TCP port 8083), which is often not externally exposed but may be reachable from internal network segments, shared infrastructure, or compromised adjacent systems. Second, the attacker must be able to influence or manipulate responses from the HTTP Event Collector endpoint targeted by the connector - this requires either a man-in-the-middle position on the network path between the connector and Splunk Enterprise, DNS-level interception of the HEC target hostname, or the ability to reconfigure the connector via the REST API to point to an attacker-controlled HEC server. Exploitation is bounded entirely to availability impact: no data exfiltration or modification is possible. The vulnerability only affects Splunk Connect for Kafka 2.2.x below 2.2.7; deployments running 2.2.7 or later are not affected.

The CVSS 5.9 medium rating (AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:H) accurately reflects the dual-condition exploitation requirement: an attacker must both reach the Kafka Connect REST API over the network and independently influence HEC endpoint responses - implying a man-in-the-middle network position, DNS manipulation, or the ability to configure the connector to target a malicious HEC endpoint, which meaningfully constrains opportunistic exploitation. No EPSS data was included in the provided intelligence, and the vulnerability is absent from the CISA Known Exploited Vulnerabilities catalog with no confirmed public proof-of-concept code. The impact is narrowly scoped to availability - specifically, the Kafka-to-Splunk data ingestion pipeline stalls - with no confidentiality or integrity consequences, ruling out data theft or manipulation scenarios. Organizations running security operations centers or compliance-driven logging pipelines dependent on this connector face the most significant operational risk, as a successful exploit would blind downstream Splunk detection or audit systems. The absence of KEV listing and confirmed exploit code supports treating this as a scheduled patching priority rather than an emergency response, though the 2.2.7 fix is straightforward and low-risk to apply.

An attacker with a network position allowing access to both the Kafka Connect REST API and the path between the connector and the Splunk HEC endpoint - for example via an internal network compromise or DNS poisoning - sends persistent HTTP failure responses to the HEC endpoint, triggering the connector's unbounded retry loop. The connector continuously retries failed event batches without limit, consuming processing resources until event delivery stops entirely and the Kafka-to-Splunk ingestion pipeline is silently blinded. No public proof-of-concept code has been identified, and the dual network positioning requirement means this attack demands moderate adversarial sophistication.