CVE-2026-76400

CVE-2026-76400 in Splunk Connect for Kafka exposes an algorithmic resource exhaustion vulnerability in how the connector handles HEC (HTTP Event Collector) delivery failures. An attacker who can trigger HEC delivery failures — through network manipulation, endpoint overloading, or direct response control — forces the connector into an unbounded retry loop. The connector doesn't crash; it stalls, consuming host resources indefinitely while the Kafka pipeline continues producing events that never reach Splunk. This is a silent operational failure, which is harder to detect than a hard crash. The CVSS 5.9 rating is misleading. The prerequisite of 'ability to influence HEC responses' is far narrower than the actual attack surface. Any condition causing HEC delivery failures — network instability, Splunk overload, or deliberate manipulation — can trigger the infinite retry condition. The vulnerability is the absence of defensive retry design: no timeout, no backoff, no circuit breaker. The connector assumes delivery will eventually succeed and blocks on that assumption. Version 2.2.7 introduces a finite retry limit, but this creates a new failure mode operators must understand. The retry limit may be hardcoded and non-configurable. When exhausted, the connector's behavior is unclear — does it fail gracefully and log, or does it silently drop data? Without visibility into retry exhaustion events, operators have traded a silent infinite loop for silent data loss. You need to verify whether the connector emits metrics or logs when the retry limit is hit, and you need to alert on that condition. The downstream blast radius extends beyond the connector. Kafka keeps producing, Splunk shows healthy status, but no data indexes. SOCs go blind, compliance logs develop gaps, and anomaly detection runs on incomplete data. The duration asymmetry is critical: a crash is bounded and noticed; an infinite retry loop scales with time. An attacker triggering intermittent HEC failures over days can accumulate a data gap so large that even a patched connector cannot reconstruct the timeline. Prioritize upgrading to 2.2.7. Beyond that, verify your monitoring can detect a stalled connector — check whether CPU or memory on the connector host spikes, and whether indexed event volume drops despite the connector process appearing healthy. If the retry limit is hardcoded and non-configurable, evaluate whether the default aligns with your data tolerance. This is a design flaw, not just a code bug. The connector assumed the happy path and deferred failure handling, leaving operators to discover the gaps.

Reviewed through automated stages and approved by a human before publication.