Splunk Connect for Kafka EUVD-2026-62968

Exploitation requires two specific preconditions: (1) Kerberos authentication must be the configured authentication method for the connector's HEC connection - deployments using token-based or other HEC authentication methods are not affected by this code path defect; (2) the attacker must achieve a network man-in-the-middle position between the Kafka connector and the Splunk HEC endpoint, which requires either compromised network infrastructure, Layer 2 access to the same network segment, or the ability to manipulate routing. The CVSS AC:H vector reflects this positioning requirement. Exploitation is further limited to Splunk Connect for Kafka 2.2.x versions strictly below 2.2.7; upgraded instances are not affected. There is no user interaction required once the attacker is positioned, and no authentication against the target system is needed.

The CVSS 3.1 score of 7.4 (AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:N) reflects an accurate picture: network attack vector is correct since the connector communicates with HEC over a network path, but AC:H appropriately captures the requirement that the attacker must be physically or logically interposed in the network path (e.g., via ARP spoofing, rogue routing, or compromised network infrastructure). PR:N is correct because the attacker does not need credentials on the affected system - they exploit the passive certificate bypass. The dual high impact on confidentiality and integrity (C:H/I:H) is significant: an attacker can read all Splunk-bound event data (log exfiltration) and silently alter it (log tampering, a severe forensic and SIEM integrity concern). No EPSS score was provided in the input data, so quantitative exploitation probability cannot be stated. No public exploit code or POC has been identified, and the vulnerability is not listed in CISA KEV. The AC:H constraint substantially limits opportunistic exploitation - this is most plausible in targeted attacks against environments with known network access, not mass scanning campaigns. The additional prerequisite of Kerberos authentication being configured for HEC (non-default in many deployments) further reduces the realistic at-risk population.

An attacker with access to a network segment between the Kafka connector host and the Splunk HEC endpoint performs ARP poisoning or BGP route injection to redirect connector-to-HEC traffic through an attacker-controlled proxy. Because the Kerberos code path skips certificate validation, the connector accepts the attacker's self-signed or forged certificate, allowing full decryption of the TLS stream. The attacker passively exfiltrates sensitive log and event data flowing into Splunk, or actively modifies log entries before forwarding them to HEC, corrupting the SIEM's visibility into security events. No public exploit code is available at time of analysis.