CVE-2026-76342 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 holds the "power" Splunk role could store risky Search Processing Language (SPL) commands in a Table Editor dataset and share the dataset. A user who holds the "admin" Splunk role triggers the commands when that user opens the dataset in the Table Editor. The commands run using the permissions of the second user and could expose all relevant data and modify lookup files. The vulnerability is possible because the Table Editor does not apply SPL safeguards for risky commands to the field-summary search that it runs for the Initial Data step. The vulnerability requires the attacker to phish the affected user by tricking them into initiating a request within their browser. The user who holds the "power" Splunk role should not be able to exploit the vulnerability at will. For more information see SPL safeguards for risky commands (https://help.splunk.com/en/splunk-enterprise/administer/manage-users-and-security/10.2/best-practices-for-splunk-platform-security/spl-safeguards-for-risky-commands) and Define roles on the Splunk platform with capabilities (https://help.splunk.com/en/splunk-enterprise/administer/manage-users-and-security/10.2/manage-splunk-platform-users-and-roles/define-roles-on-the-splunk-platform-with-capabilities) in the Splunk documentation.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 08/20/2026
A critical security vulnerability exists within Splunk Enterprise versions prior to 10.4.2, 10.2.6, 10.0.9, and 9.4.14, involving a privilege escalation mechanism facilitated through the Table Editor feature. This flaw allows a user with the "power" role, which typically grants limited administrative capabilities for search and reporting but not full system administration, to execute commands that require higher privileges when accessed by an administrator. The core of the vulnerability lies in how Splunk handles Search Processing Language (SPL) safeguards during specific data retrieval operations. Specifically, the Table Editor fails to apply necessary SPL safeguards for risky commands during the field-summary search executed as part of its Initial Data step. This oversight creates a pathway where maliciously crafted datasets can bypass standard security controls designed to restrict dangerous functionality.
The exploitation scenario requires social engineering or phishing tactics directed at a user holding the "admin" Splunk role. An attacker with the "power" role constructs a dataset containing risky SPL commands and shares this dataset within the environment. When an administrator opens this shared dataset in the Table Editor, the system automatically triggers the field-summary search to populate the view. Because the safeguards are not applied at this stage, the risky commands execute under the context of the administrator user rather than the creator of the dataset. This effectively elevates the privileges of the "power" user for the duration and scope of that specific operation, allowing them to perform actions normally reserved for administrators.
The operational impact of this vulnerability is severe, as it compromises both data confidentiality and integrity within the Splunk platform. By leveraging the elevated permissions gained through this flaw, an attacker can expose all relevant data accessible to the administrator account, leading to significant information disclosure. Furthermore, the ability to modify lookup files means that attackers can alter critical configuration data used by searches across the organization. This could lead to further persistence mechanisms or additional privilege escalation vectors if malicious lookups are deployed broadly. The vulnerability highlights a dangerous gap in role-based access control enforcement where UI-driven actions bypass backend security checks intended for direct command execution.
To mitigate this risk, organizations must immediately upgrade Splunk Enterprise to version 10.4.2, 10.2.6, 10.0.9, or 9.4.14, or any later patched release where these safeguards are correctly implemented in the Table Editor's data retrieval process. In addition to patching, administrators should review and restrict SPL capabilities assigned to users with the "power" role, ensuring they do not possess unnecessary permissions that could be abused if safeguards fail. It is also advisable to enforce strict access controls on dataset sharing and monitor for unusual activity involving field-summary searches or lookup file modifications. Adhering to Splunk's best practices for managing user roles and capabilities will help minimize the attack surface associated with such privilege escalation flaws.
From a classification perspective, this vulnerability aligns with CWE-269, Improper Privilege Management, as it allows an actor to gain privileges they are not authorized to have through a specific application feature. It also relates to CWE-78, Improper Neutralization of Special Elements used in an OS Command, given the execution of risky SPL commands that function similarly to operating system commands within the Splunk environment. In terms of attack tactics, this scenario reflects ATT&CK technique T1068, Exploitation for Privilege Escalation, where a lower-privileged user exploits a flaw to gain higher-level access. The requirement for phishing indicates an initial vector consistent with social engineering attacks aimed at compromising high-value targets within the infrastructure.