CVE-2026-76270 in Splunk
Summary
by MITRE • 10/08/2026
In Splunk Enterprise versions below 10.4.3, a user that holds a role with the list_spl2_modules capability could use SQL injection in SPL2 module filtering to access all relevant data available through the affected Representational State Transfer (REST) API, including private SPL2 module definitions belonging to other users. The vulnerability is possible because Splunk Enterprise and Splunk Cloud Platform do not parameterize user-supplied values before using them in database queries for SPL2 module filtering. For more information see Manage SPL2 modules (https://help.splunk.com/en/splunk-enterprise/search/spl2-search-manual/multiple-searches-in-an-spl2-module/manage-spl2-modules) and Module permissions (https://help.splunk.com/en/splunk-enterprise/search/spl2-search-manual/modules-statements-and-views/module-permissions) in the Splunk documentation.
Splunk Enterprise versions 10.2.x, 10.0.x, and 9.4.x are not affected.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 10/08/2026
A critical security vulnerability has been identified within Splunk Enterprise versions prior to 10.4.3, specifically affecting the handling of SPL2 module filtering operations. This flaw allows authenticated users possessing a role with the list_spl2_modules capability to execute SQL injection attacks against the underlying database queries used for filtering modules. The root cause lies in the application's failure to properly parameterize user-supplied input values before incorporating them into Structured Query Language statements. Instead of using prepared statements or safe query construction methods, the system directly concatenates unsanitized user inputs into the query string, creating a classic injection vector that can be exploited by malicious actors with relatively low privilege levels.
The operational impact of this vulnerability is significant as it enables unauthorized data access across multiple users within the Splunk environment. By crafting specific SQL payloads through the SPL2 module filtering interface, an attacker can bypass intended access controls and retrieve all relevant data exposed via the affected Representational State Transfer API. This includes sensitive private SPL2 module definitions belonging to other users, which may contain proprietary search logic, internal infrastructure details, or credentials embedded within those modules. The ability to exfiltrate this information compromises the confidentiality of organizational knowledge assets and potentially reveals architectural patterns that could facilitate further attacks against the Splunk deployment or connected systems.
From a classification perspective, this vulnerability aligns with CWE-89 Improper Neutralization of Special Elements used in an SQL Command, commonly known as SQL Injection. The attack vector leverages the application's input validation failure to manipulate backend database operations, which is also consistent with ATT&CK technique T1059 Command and Scripting Interpreter if the injection leads to broader command execution, though primarily it falls under data exfiltration via API abuse in this context. The vulnerability highlights a critical gap in secure coding practices where user-supplied values are not adequately sanitized or parameterized before database interaction, violating fundamental principles of input validation and output encoding required for robust application security.
To mitigate this risk, organizations running affected versions must upgrade to Splunk Enterprise version 10.4.3 or later immediately upon availability. Until the patch is applied, administrators should strictly enforce role-based access control policies by removing the list_spl2_modules capability from any roles that do not absolutely require it for business operations. Additionally, network-level controls such as Web Application Firewalls can be configured to detect and block common SQL injection patterns in API requests targeting SPL2 module endpoints. Regular security audits of user permissions and continuous monitoring for anomalous query patterns in the Splunk audit logs are recommended to identify potential exploitation attempts while maintaining strict adherence to least privilege principles across allSplunk roles.