CVE-2026-76318 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 that holds a role with the schedule_search capability could store a malicious script in an alert trigger condition field. When another user opens the crafted link, the script runs in the browser of that user and could access all data available to that user. The vulnerability is possible because Splunk Web uses the alert threshold value in generated alert trigger condition markup without escaping special characters. Successful exploitation requires another user to open the crafted link. For more information see Configure alert trigger conditions (https://help.splunk.com/en/splunk-enterprise/alert-and-respond/alerting-manual/10.4/manage-alert-trigger-conditions-and-throttling/configure-alert-trigger-conditions) 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.
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 08/20/2026
The vulnerability identified in Splunk Enterprise versions prior to 10.4.2, 10.2.6, 10.0.9, and 9.4.14 represents a critical cross-site scripting flaw rooted in the application's handling of alert trigger conditions within its web interface. This security defect allows an authenticated user possessing the schedule_search capability to inject malicious script code into the alert threshold value field during the configuration of alert triggers. The core technical failure lies in Splunk Web's processing logic, which fails to properly escape special characters when generating the markup for alert trigger conditions. Consequently, any content entered by a privileged user is rendered as executable HTML and JavaScript rather than being treated strictly as data or text parameters within the application interface.
The operational impact of this vulnerability extends beyond the initial actor who creates the malicious configuration. Because Splunk Enterprise relies heavily on role-based access control to manage data visibility, the exploitation scenario involves a secondary victim. When another user with different permissions opens a link associated with the crafted alert trigger condition, their browser executes the injected script within the context of that user's session. This execution environment grants the attacker the ability to perform actions and access all data available to the targeted user, effectively bypassing intended security boundaries through client-side code injection rather than server-side privilege escalation.
From a classification perspective, this vulnerability aligns with CWE-79, which describes Improper Neutralization of Input During Web Page Generation commonly known as Cross-site Scripting (XSS). The specific mechanism involves stored XSS elements where the malicious payload is saved on the target system and subsequently retrieved by other users. In terms of adversary tactics, this behavior corresponds to ATT&CK technique T1059 Command and Scripting Interpreter via browser-based execution, allowing for potential data exfiltration or session hijacking depending on the capabilities granted to the victim user's role. The attack vector is primarily social engineering combined with legitimate administrative actions, requiring only that a privileged user configures an alert condition while another user interacts with the resulting interface element.
Mitigation strategies must focus on both immediate patching and long-term architectural improvements. Administrators should immediately upgrade Splunk Enterprise to version 10.4.2 or later, where this input validation flaw has been addressed by properly sanitizing special characters in alert trigger condition fields before rendering them into the DOM. In environments where upgrading is not immediately feasible, strict role-based access control policies should be enforced to limit which users possess the schedule_search capability, thereby reducing the attack surface. Additionally, implementing a Content Security Policy (CSP) header can help mitigate the impact of any remaining XSS vulnerabilities by restricting the sources from which scripts are allowed to execute within the Splunk web interface. Regular security audits and penetration testing should also be conducted to identify similar input handling deficiencies across other configurable fields in the platform.