CVE-2026-76320 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, an unauthenticated user could cause an authenticated user to run arbitrary Search Processing Language (SPL) searches on their behalf through the Event Type Builder. This could expose all relevant data and stored credentials. The vulnerability is possible when the Event Type Builder accepts cross-site request input and retains SPL-affecting values while building sample event searches. 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. For more information see Automatically find and build event types (https://help.splunk.com/en/splunk-enterprise/manage-knowledge-objects/knowledge-management-manual/9.0/event-types/automatically-find-and-build-event-types) in the Splunk documentation.
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 08/20/2026
The identified vulnerability represents a critical security flaw within Splunk Enterprise versions prior to 10.4.2, 10.2.6, 10.0.9, and 9.4.14, specifically affecting the Event Type Builder functionality. This component is designed to assist users in automatically discovering patterns in log data to create event types for easier searching and analysis. However, the implementation contains a logic error that allows an unauthenticated attacker to leverage cross-site request forgery techniques against authenticated administrators or power users. The core technical flaw lies in the Event Type Builder's failure to properly validate the origin of requests while retaining sensitive Search Processing Language parameters during the construction of sample event searches. By accepting inputs from external sources without adequate verification, the application inadvertently allows an attacker to inject malicious SPL commands that are executed under the context of the victim user who is logged into the Splunk instance.
The operational impact of this vulnerability is severe due to the high privileges typically associated with users interacting with knowledge objects and event types in a Splank environment. When an authenticated user is tricked into initiating a request, such as by clicking on a malicious link or loading a compromised webpage while their session is active, the application processes the injected SPL commands. This results in arbitrary code execution within the search context of that user. Consequently, this can lead to the exfiltration of all relevant data indexed within the Splunk environment, including sensitive logs and potentially stored credentials used for various integrations or lookups. The attacker does not need direct authentication to exploit this flaw; instead, they rely on social engineering tactics to compel a privileged user to perform actions that compromise their own session security.
From a classification perspective, this vulnerability aligns with CWE-352, which describes Cross-Site Request Forgery (CSRF). The attack vector requires the victim's browser to send authenticated requests to the vulnerable application while maintaining valid session cookies or tokens. Furthermore, in the context of the MITRE ATT&CK framework, this behavior corresponds to techniques involving Command and Scripting Interpreter abuse, specifically where an attacker uses a trusted user's credentials to execute commands that facilitate data exfiltration. The reliance on phishing indicates that initial access is achieved through social engineering rather than direct technical exploitation of network services, highlighting the importance of both technical controls and security awareness training in mitigating such risks.
Mitigation strategies must focus primarily on upgrading the Splunk Enterprise installation to version 10.4.2 or later, where these specific logic flaws have been addressed by the vendor. For environments that cannot immediately upgrade, administrators should implement strict access controls for the Event Type Builder feature, ensuring that only trusted users with a need-to-know can utilize it. Additionally, deploying web application firewalls to detect and block anomalous request patterns associated with CSRF attacks can provide an additional layer of defense. It is also critical to enforce short session timeouts and require re-authentication for sensitive operations involving knowledge objects or data access configurations. Regular audits of user activity logs should be conducted to identify any unauthorized attempts to manipulate event types or execute unusual SPL searches, thereby enabling rapid detection and response to potential exploitation attempts.