CVE-2026-76341 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 attacker-controlled Search Processing Language (SPL) in a Table Editor dataset and share the dataset. A user who holds the "admin" Splunk role triggers the SPL when that user opens the dataset in the Table Editor. The SPL runs using the permissions of the second user and could expose all relevant data and modify limited data on the search head. The vulnerability is possible because the Table Editor does not apply SPL safeguards for risky commands when it prepares the dataset initial data. 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 Define initial data for a new table dataset (https://help.splunk.com/en/splunk-enterprise/manage-knowledge-objects/knowledge-management-manual/9.4/create-and-edit-table-datasets/define-initial-data-for-a-new-table-dataset), 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.4/manage-splunk-platform-users-and-roles/define-roles-on-the-splunk-platform-with-capabilities) in the Splunk documentation.
If you want to get best quality of vulnerability data, you may have to visit VulDB.
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 flaw in how the Table Editor component handles Search Processing Language (SPL) commands during dataset initialization. The vulnerability stems from an insufficient validation mechanism where the application fails to apply necessary SPL safeguards for risky commands when preparing initial data for a new table dataset. This architectural oversight allows a user possessing the "power" Splunk role, which is typically intended for advanced search and reporting but not administrative control, to inject attacker-controlled SPL code into a shared dataset configuration. The core technical failure lies in the lack of sanitization or restriction on specific high-risk SPL commands during the data preparation phase, effectively bypassing standard security controls that would normally prevent such execution contexts from being established by lower-privileged users.
The operational impact of this vulnerability is significant due to its reliance on social engineering and privilege escalation through role-based access control exploitation. An attacker with "power" privileges can craft a malicious dataset containing the injected SPL code and share it within the Splunk environment. The exploit triggers when another user, specifically one holding an "admin" role or other elevated permissions that allow opening datasets in the Table Editor, views this shared content. Upon loading the dataset, the system executes the embedded SPL commands using the security context of the viewing admin user rather than the creator. This results in a privilege escalation scenario where low-privileged code execution is promoted to high-privileged administrative actions without direct authentication bypass or credential theft.
The consequences of successful exploitation include the potential exposure of all sensitive data accessible within the Splunk instance, as well as the ability for the attacker to modify limited data on the search head through the elevated permissions granted during command execution. This represents a severe breach of confidentiality and integrity principles in information security. The attack vector is classified as requiring user interaction, specifically necessitating that an administrator be phished or tricked into opening the malicious dataset within their browser environment. Consequently, this vulnerability aligns with CWE-94 Improper Control of Generation of Code (Code Injection) regarding the injection of SPL commands and relates to ATT&CK techniques involving Command and Scripting Interpreter abuse for lateral movement and data exfiltration within enterprise environments.
To mitigate this risk, organizations must immediately upgrade Splunk Enterprise to version 10.4.2 or later, where these safeguards have been implemented in the Table Editor logic. Until patching is complete, administrators should restrict access to shared datasets containing initial data definitions from users with "power" roles and enforce strict review processes for any dataset modifications. Additionally, implementing least-privilege principles by limiting who can create or share table datasets can reduce the attack surface. Security teams should also monitor for unusual SPL command executions originating from standard user accounts versus administrative contexts to detect potential exploitation attempts in real-time.