Splunk Enterprise CVE-2026-76345

Exploitation requires an authenticated Splunk account holding a high-privilege Splunk role that specifically grants the ability to manage search head clustering (the 'can_srchhead_cluster_manage' or equivalent capability). Standard admin-level users without explicit SHC management rights are not sufficient. The target deployment must be running Splunk Enterprise in a search head cluster configuration - standalone Splunk instances without SHC configured would not expose the vulnerable API endpoint. Versions below 10.4 are explicitly immune per the vendor advisory. The Splunk REST API port (default 8089) must be reachable by the attacker, which is typically restricted to internal networks but accessible from any authenticated client with network reach. Exploitation is limited by the OS-level write permissions of the account running Splunk - files can only be written where that service account has access, constraining but not eliminating the impact.

The CVSS 3.1 base score of 6.0 (AV:N/AC:L/PR:H/UI:N/S:U/C:H/I:L/A:L) reflects that exploitation requires high privileges (PR:H), which significantly constrains the attacker population to insiders, compromised admin accounts, or privilege-escalated sessions. The C:H rating is consistent with the vendor statement that all relevant Splunk data could be accessed post-exploitation. However, the vendor's I:L/A:L ratings appear conservative given that successful file-write-to-RCE inherently yields full integrity and availability compromise of the Splunk deployment; the true post-exploitation impact is likely higher and the vendor rating may reflect a bounded scope assessment. No EPSS data was provided in the intelligence feed, and the CVE is not listed in CISA KEV, suggesting no confirmed active exploitation at time of analysis. Cisco reported the issue, indicating external discovery rather than vendor self-identification. Real-world priority should be HIGH for organizations running Splunk 10.4 or 10.4.1, particularly those with multiple high-privilege users or federated identity integrations that could expose SHC management roles to broader account populations.

An attacker who has obtained or possesses a Splunk account with a high-privilege role that includes search head cluster management rights authenticates to the Splunk REST API over the network and submits a crafted bundle archive containing a path-traversed payload path. The server writes the malicious file - such as a web shell or a Splunk app configuration that executes OS commands - to a location writable by the Splunk daemon, and the attacker subsequently triggers execution by referencing the written file through a legitimate Splunk mechanism. No public POC has been identified, but the primitive (authenticated REST write to arbitrary path) is well understood and exploitable by a skilled attacker without specialized tooling.