Splunk Enterprise CVE-2026-76314

Exploitation requires a valid Splunk Enterprise user account that does NOT hold the 'admin' or 'power' Splunk role - any lower-privileged authenticated account is sufficient. Splunk Web must be enabled and network-reachable from the attacker's position; environments where Splunk Web is disabled or where the Splunk web port (default 8000/tcp) is restricted to administrator-only subnets are not directly exposed to remote exploitation. The specific trigger is submitting crafted XML content to the manager configuration route within Splunk Web. Limiting factors: unauthenticated external attackers cannot exploit this without first obtaining valid Splunk credentials; Splunk instances with Splunk Web disabled on the target node are not vulnerable via this vector. No special OS-level access, non-default feature flag, or unusual deployment topology is required beyond the above.

The CVSS 3.1 vector AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H scoring 8.8 accurately reflects the threat profile: network-exploitable, no special conditions, minimal authentication, and full C/I/A compromise. The low attack complexity signals that exploitation requires no race conditions, specific timing, or unusual target state - the attack path is deterministic once a valid low-privilege account is in hand. EPSS data was not included in the provided intelligence, so probabilistic exploitation likelihood cannot be quantified from that signal; however, the dual failure mode (both input validation and access control) presents a well-bounded, discoverable vulnerability surface. The CVE is not listed in CISA KEV and no public proof-of-concept is known at time of analysis - these are meaningful moderating factors. That said, the combination of network accessibility, low privilege bar, and full-system impact means that even a modestly resourced attacker with a standard Splunk account could achieve complete host compromise, and the remediation timeline should be treated as urgent. Cisco's discovery and disclosure adds credibility to the technical findings.

An attacker with a standard Splunk user account - obtained through credential phishing, password reuse, or an internally provisioned account - sends a crafted HTTP request containing malicious XML to the Splunk Web Manager Configuration endpoint. Because the route does not enforce the required capability check, the request is accepted and the XML is evaluated server-side, triggering code injection. The attacker gains code execution under the Splunk process identity, enabling data exfiltration and system manipulation. No public proof-of-concept is known at time of analysis, but the attack path requires no special tooling beyond the ability to craft an HTTP request.