Splunk Connect for Kafka EUVD-2026-62966

The Kafka Connect REST API must be reachable from the attacker's network position without requiring authentication - the CVSS PR:N confirms unauthenticated access to this API is the assumed condition. The connector must have the timestamp extraction feature enabled or the attacker must have the ability to reconfigure it via the REST API (which the description explicitly states is possible unauthenticated). Exploitation additionally requires that event data matching the crafted regex reaches the connector, either by injecting records into the Kafka topic or by waiting for naturally occurring matching data. AC:H in the CVSS vector reflects these two combined preconditions (crafted regex configuration plus matching trigger data). Exploitation is bounded by: the Kafka Connect REST API being network-isolated or firewall-restricted (common in well-secured deployments), the need to produce or wait for matching event data, and the single-connector scope - only the targeted connector is affected, not the entire Kafka broker or other connectors.

The provided CVSS 5.9 (AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:H) accurately captures the risk profile: network-reachable and unauthenticated exploitation is possible, but AC:H acknowledges the dual precondition - the attacker must both submit a crafted regex and ensure matching event data flows through the connector. In environments where the Kafka Connect REST API is exposed on a network segment accessible to untrusted parties (a common misconfiguration in on-premises Kafka deployments), the lack of authentication requirement (PR:N) elevates real-world risk significantly. The impact is purely availability (C:N/I:N/A:H), meaning confidential data is not at risk, but disruption to the Splunk data pipeline could impair security monitoring or operational analytics depending on the connector's role. No EPSS data is provided in the input, and there is no CISA KEV listing or known public POC, suggesting opportunistic exploitation is not currently observed. The 'Information Disclosure' tag in the source data appears to be misapplied - the CVSS vector and description confirm this is a pure availability/DoS vulnerability with no confidentiality or integrity component; analysts should disregard that tag. Real priority is moderate: environments exposing the REST API without network controls should patch promptly, while those with properly isolated Kafka Connect deployments face lower urgency.

An attacker with network access to an unprotected Kafka Connect REST API endpoint sends a PUT or POST request configuring a connector's timestamp extraction parameter with a ReDoS pattern such as a nested-quantifier regex. When Kafka event records matching the trigger string subsequently flow through the connector - either naturally from the topic or injected by the attacker - the regex engine enters catastrophic backtracking, permanently consuming the worker thread's CPU and halting all further record delivery from that connector without error recovery. No public POC has been identified, but the attack primitive (ReDoS via API-supplied regex) is well-understood and the construction of a working payload requires only basic knowledge of regex backtracking behavior.