CVE-2026-76334 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 a Dashboard Studio workflow action containing attacker-controlled Search Processing Language (SPL). When another authenticated user selects the action from Event Actions and selects Continue, Splunk Enterprise runs the injected SPL using the permissions of that user. The injected SPL could access or modify data available to that user. The vulnerability is possible because Dashboard Studio does not sufficiently validate workflow-action URLs before submitting requests. 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.
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 08/20/2026
Splunk Enterprise versions prior to 10.4.2, 10.2.6, 10.0.9, and 9.4.14 contain a critical security flaw within the Dashboard Studio component that allows for unauthorized execution of Search Processing Language commands through social engineering tactics. The vulnerability stems from insufficient validation of workflow-action URLs when they are submitted by users with elevated privileges, specifically those holding the power role. This architectural weakness enables an attacker to craft malicious dashboard configurations containing arbitrary SPL code, which is then executed within the context of any authenticated user who interacts with the compromised element.
The technical mechanism involves a cross-site request forgery-like scenario where the attack relies on tricking a victim into initiating a specific action within their browser session. An adversary possessing the power role can embed attacker-controlled Search Processing Language commands into a Dashboard Studio workflow action. When another authenticated user views this dashboard and selects the malicious action from Event Actions, subsequently choosing to continue, Splunk Enterprise processes the request without adequately sanitizing or validating the underlying URL parameters that trigger the search execution. Consequently, the injected SPL runs with the permissions of the victim user rather than the creator of the dashboard.
This flaw results in a significant operational impact as it allows for potential data exfiltration or modification of information accessible to the targeted user. Since Splunk is often used to store sensitive security logs and organizational intelligence, an attacker could leverage this vulnerability to read confidential audit trails, modify log integrity, or execute commands that compromise the confidentiality and integrity of the SIEM platform. The attack vector requires active social engineering because it depends on a legitimate user clicking through a malicious interface element, making stealthy persistence difficult but highly effective if successful.
From an industry standard perspective, this vulnerability aligns with CWE-94 Improper Control of Generation of Code or Command and CWE-798 Use of Hard-coded Credentials in the context of privilege escalation via role-based access control failures. In terms of MITRE ATT&CK framework classification, it maps to T1059 Command and Scripting Interpreter through SPL execution and potentially T1132 Data Encoding for obfuscation if encoded payloads are used. The scenario also reflects aspects of T1566 Phishing as the initial access vector relies on deceiving users into interacting with malicious content.
Mitigation strategies must prioritize immediate patching to the latest stable release where this validation logic has been corrected. Organizations should enforce strict least-privilege principles by auditing and restricting the power role, ensuring that only trusted administrators can create or modify dashboard configurations containing workflow actions. Additionally, implementing input validation controls on all user-supplied data entering the Dashboard Studio module is essential. Security teams should also monitor for unusual SPL query patterns originating from standard user accounts to detect potential exploitation attempts in real-time before significant damage occurs.