CVE-2026-76324 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 create a malicious Splunk Web tour and cause arbitrary JavaScript to run in the browser of another user when that user opens a crafted tour link. The JavaScript runs in the browser of the affected user, allowing for access to all relevant data available to that user. The Cross-Site Scripting (XSS) vulnerability is possible because Splunk Web renders tour content and tour navigation links without sufficient output encoding and accepts a tour selector value that can be treated as markup. The vulnerability requires another user to open a crafted tour link. The user who holds the "power" Splunk role should not be able to trigger JavaScript execution in another user's browser without that user interaction.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 08/20/2026
The identified security flaw resides within Splunk Enterprise software, specifically affecting versions prior to 10.4.2, 10.2.6, 10.0.9, and 9.4.14. This vulnerability is classified as a Stored Cross-Site Scripting issue that exploits the application's handling of user-generated content within its web interface tours feature. The core technical deficiency lies in the insufficient output encoding applied to tour content and navigation links when rendered by Splunk Web. Furthermore, the system accepts a tour selector value without adequate sanitization, allowing this input to be interpreted as executable markup rather than plain text data. This lack of proper validation enables an attacker with specific privileges to inject malicious JavaScript payloads directly into the application's response stream.
The exploitation scenario requires two distinct actors within the Splunk environment. First, an authenticated user possessing the "power" role must create a malicious tour containing the crafted script payload. Second, this vulnerability relies on social engineering or link sharing tactics where another victimized user is induced to open the specific URL associated with the attacker's crafted tour. Upon accessing this link, the browser parses and executes the embedded JavaScript within the context of the Splunk Web application domain. Because the code runs in the victim's session, it inherits all permissions and data access rights granted to that user account by the platform's role-based access control mechanisms.
The operational impact of this vulnerability is significant due to its ability to bypass standard authentication boundaries through session hijacking techniques inherent to XSS attacks. Once the malicious script executes, an attacker can perform a variety of hostile actions depending on the victim's privileges. These actions may include exfiltrating sensitive search results and configuration data, modifying user settings without authorization, or performing actions that appear legitimate from the server side because they are authenticated with the victim's credentials. This effectively allows unauthorized access to all relevant data available to the targeted user, compromising confidentiality and potentially integrity depending on the scripts' capabilities.
From a classification perspective, this vulnerability aligns with CWE-79 Improper Neutralization of Input During Web Page Generation commonly known as Cross-site Scripting. The attack vector corresponds to ATT&CK technique T1059 Command and Scripting Interpreter via browser-based execution, specifically leveraging stored payloads that persist within the application's database or configuration until triggered by a victim. This persistence mechanism distinguishes it from reflected XSS attacks, making detection more challenging for security monitoring tools as the malicious code is embedded in legitimate-looking tour structures rather than transient URL parameters.
Mitigation strategies primarily involve upgrading to Splunk Enterprise version 10.4.2 or later where these input validation and output encoding issues have been addressed by the vendor. In environments where immediate patching is not feasible, administrators should enforce strict role-based access controls to limit who holds the "power" role, thereby reducing the pool of potential attackers capable of creating malicious tours. Additionally implementing a Content Security Policy can help mitigate the impact by restricting script execution sources and preventing unauthorized data exfiltration even if an XSS payload successfully executes within the browser context. Regular security audits of user-generated content features are also recommended to identify similar encoding deficiencies in other parts of the application interface.