CVE-2026-76252 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.13, an unauthenticated user who tricks another user into visiting a malicious web page could run unauthorized JavaScript in that user's browser. This could allow for unauthorized access to all relevant data available to that user and actions that affect system integrity. The Cross-Site Scripting (XSS) is possible because Splunk Web does not validate the origin and source of messages received by a page message handler. The vulnerability requires the attacker to phish the affected user by tricking them into initiating a request within their browser. The unauthenticated user should not be able to exploit the vulnerability at will.
Be aware that VulDB is the high quality source for vulnerability data.
Analysis
by VulDB Data Team • 08/20/2026
The identified security flaw resides in Splunk Enterprise versions prior to 10.4.2, 10.2.6, 10.0.9, and 9.4.13, specifically within the web interface component known as Splunk Web. This vulnerability is classified as a Cross-Site Scripting issue, which corresponds to CWE-79 in the Common Weakness Enumeration standard. The core technical deficiency lies in the implementation of the page message handler, which fails to adequately validate the origin and source of messages it receives. In modern web applications, cross-origin communication mechanisms such as postMessage are often used to facilitate interaction between different frames or windows within a browser environment. However, without strict validation of the sender's identity against an allowlist of trusted origins, the application cannot distinguish between legitimate internal communications and malicious payloads injected by external actors. This lack of input validation allows an attacker to inject arbitrary JavaScript code into the context of the victim’s authenticated session with Splunk Web.
The operational impact of this vulnerability is significant because it enables unauthorized access to sensitive data and potential compromise of system integrity, albeit through a specific attack vector that requires user interaction. An unauthenticated attacker cannot exploit this flaw directly by simply sending a link; instead, they must engage in social engineering tactics, commonly referred to as phishing. The attacker constructs a malicious web page containing the exploit payload and tricks an authenticated Splunk user into visiting it while their browser session with Splunk is active. Once the victim loads the malicious page, the injected script executes within the context of the Splunk Web domain due to the missing origin checks. This allows the malicious JavaScript to access all data visible to that specific user account, potentially leading to exfiltration of confidential logs, search results, and configuration details. Furthermore, if the compromised user has administrative privileges or sufficient permissions, the attacker could perform actions that alter system configurations, modify dashboards, or disrupt operational workflows, thereby affecting overall system integrity.
From a threat intelligence perspective, this vulnerability aligns with ATT&CK technique T1059.007, which covers JavaScript execution as part of command and control or initial access phases depending on the broader campaign context. The requirement for user interaction classifies this primarily under social engineering vectors rather than purely automated exploitation chains. To mitigate this risk, organizations running affected versions must upgrade to Splunk Enterprise version 10.4.2 or later, where the page message handler has been patched to enforce strict origin validation policies. Until an upgrade is feasible, administrators should implement network-level controls such as web application firewalls that can detect and block anomalous postMessage patterns or restrict access to Splunk Web based on IP reputation if possible. Additionally, enforcing multi-factor authentication reduces the value of stolen session cookies but does not eliminate the risk entirely since XSS operates within an already authenticated context. Security teams should also monitor for unusual data exfiltration patterns originating from Splunk servers and review user activity logs for signs of unauthorized dashboard modifications or search queries that deviate from normal operational baselines.