CVE-2026-76296 in Splunk
Summary
by MITRE • 10/22/2026
In Splunk Enterprise versions below 10.4.4, 10.2.8, 10.0.11, and 9.4.16, a user who does not hold the "admin" or "power" Splunk roles could create, move, edit, or delete sourcetype renaming configurations that they own in apps that they do not have permission to access. The vulnerability is possible when Splunk Web is turned on because Splunk Web does not verify the required app permissions before it performs sourcetype renaming operations. For more information see Rename source types at search time (https://help.splunk.com/en/splunk-enterprise/get-started/get-data-in/10.6/configure-source-types/rename-source-types-at-search-time) in the Splunk documentation.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 10/22/2026
The identified vulnerability in Splunk Enterprise versions prior to 10.4.4, 10.2.8, 10.0.11, and 9.4.16 represents a critical failure in access control logic within the web-based management interface known as Splunk Web. This flaw allows users with limited privileges who lack the admin or power roles to manipulate sourcetype renaming configurations for apps they are not authorized to access. The core technical deficiency lies in the server-side validation process, where Splunk Web fails to verify that the requesting user possesses the necessary permissions for the specific application context before executing operations related to source type renaming at search time. This oversight effectively bypasses the intended role-based access control mechanisms designed to isolate data and configuration management between different applications within a multi-tenant or segmented environment.
From a technical perspective, this vulnerability is classified as an Insecure Direct Object Reference combined with Broken Access Control. The attacker leverages their ability to create, move, edit, or delete sourcetype renaming configurations that they own but applies these actions against resources belonging to restricted applications. By manipulating the HTTP requests sent to Splunk Web, a low-privileged user can alter how data is interpreted and searched within apps where they should have no write access. This capability undermines the integrity of search time transformations, which are crucial for correctly categorizing incoming log data into appropriate sourcetypes that dictate parsing rules and field extractions.
The operational impact of this vulnerability is significant in environments relying on Splunk Enterprise for security monitoring and incident response. An attacker could potentially cause denial of service by misconfiguring sourcetype renames, leading to incorrect data classification or loss of visibility into critical events. Furthermore, the ability to modify configurations across unauthorized apps may facilitate lateral movement within the SIEM environment, allowing an adversary to evade detection mechanisms that rely on specific log parsing rules. This could result in a complete blind spot for security teams regarding activities occurring within those restricted applications, thereby compromising the overall security posture and auditability of the system.
This vulnerability aligns with CWE-269 Improper Privilege Management and CWE-862 Missing Authorization, as it involves unauthorized access to resources due to insufficient verification of user permissions. In terms of the MITRE ATT&CK framework, this behavior corresponds to T1078 Valid Accounts, where an attacker uses legitimate credentials but exploits a flaw in authorization logic to perform actions outside their intended scope. It also relates to T1562 Impair Defenses through modification or disabling of security tools and processes, specifically by altering the configuration that governs how logs are processed and analyzed.
To mitigate this risk, organizations running affected versions must immediately upgrade Splunk Enterprise to version 10.4.4, 10.2.8, 10.0.11, or 9.4.16, which contain the necessary patches for access control validation in Splunk Web. Until an upgrade is feasible, administrators should consider disabling Splunk Web if it is not strictly required for operational workflows, thereby removing the attack vector entirely. Additionally, reviewing and tightening role-based permissions to ensure that users only have access to applications they are explicitly authorized to manage can help reduce the blast radius of such vulnerabilities in legacy deployments. Regular auditing of configuration changes within restricted apps should also be implemented to detect any unauthorized modifications promptly.