CVE-2026-76315 in Splunk
Summary
by MITRE • 08/20/2026
In Splunk Enterprise versions below 10.4.2, 10.2.6, 10.0.9, and 9.4.14, a user who does not hold the "admin" or "power" Splunk roles could execute arbitrary code on the Splunk platform instance through Splunk Web Manager Configuration. The user could then access all relevant data and affect system integrity and availability on the Splunk platform instance. The vulnerability is possible because Splunk Web Manager Configuration evaluates manager configuration values, and the Representational State Transfer (REST) API path for manager configuration does not require the permission that normally controls manager configuration writes. For more information see About configuring role-based user access (https://help.splunk.com/en/splunk-enterprise/administer/manage-users-and-security/10.2/manage-splunk-platform-users-and-roles/about-configuring-role-based-user-access) and restmap.conf (https://help.splunk.com/en/data-management/splunk-enterprise-admin-manual/10.2/configuration-file-reference/10.2.0-configuration-file-reference/restmap.conf) in the Splunk documentation.
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 08/20/2026
A critical privilege escalation vulnerability exists within Splunk Enterprise versions prior to 10.4.2, 10.2.6, 10.0.9, and 9.4.14, allowing unprivileged users to achieve arbitrary code execution on the platform instance. This flaw resides in the Splunk Web Manager Configuration component, specifically within how the Representational State Transfer API handles configuration updates. Under normal operational parameters, access to manager configuration settings is strictly gated by role-based permissions, requiring either admin or power roles to modify system-level configurations. However, due to a logic error in the REST API path evaluation for these specific versions, the permission check required to write manager configuration values was bypassed. This misconfiguration effectively allows any authenticated user with access to Splunk Web, regardless of their assigned role, to submit maliciously crafted requests that alter critical system settings without authorization.
The technical root cause involves a failure in the enforcement of access control policies at the API layer. The REST endpoint responsible for processing manager configuration changes does not correctly validate whether the requesting user possesses the necessary privileges before applying the submitted values. This oversight creates an insecure direct object reference scenario where low-privileged users can manipulate internal system parameters that are intended to be restricted to administrators. By exploiting this gap, attackers can inject commands or modify configurations that lead to remote code execution on the underlying operating system hosting the Splunk instance. The vulnerability is classified under CWE-269 Improper Privilege Management and aligns with MITRE ATT&CK technique T1078 Valid Accounts, as it leverages legitimate authentication credentials to perform unauthorized administrative actions.
The operational impact of this vulnerability is severe, compromising the confidentiality, integrity, and availability of the Splunk platform. Once an attacker achieves arbitrary code execution through this misconfiguration, they gain full control over the affected instance. This enables them to exfiltrate sensitive data indexed by Splunk, which often includes critical security logs, network traffic analysis results, and other proprietary information. Furthermore, the ability to alter system configurations allows attackers to disable logging mechanisms, tamper with alert rules, or disrupt services entirely, leading to significant availability issues. The compromise of integrity means that forensic investigations relying on Splunk data may be rendered unreliable if an attacker has modified logs or configuration files post-exploitation.
Mitigation strategies must prioritize immediate patching and access control verification. Organizations running affected versions should upgrade to Splunk Enterprise version 10.4.2, 10.2.6, 10.0.9, or 9.4.14 immediately to resolve the underlying code defect in the REST API permission checks. In environments where patching is not instantly feasible, administrators should enforce strict network segmentation to restrict access to Splunk Web interfaces from untrusted networks and ensure that only authorized personnel have credentials for accounts with any level of administrative or power privileges. Additionally, reviewing restmap.conf configurations can help identify if custom rules are inadvertently exposing sensitive endpoints. Continuous monitoring for anomalous configuration changes initiated by low-privileged users is also recommended as a defensive measure to detect potential exploitation attempts in real time.