CVE-2026-76273 in Splunk
Summary
by MITRE • 10/07/2026
In Splunk Enterprise versions below 10.4.3, 10.2.7, 10.0.10, and 9.4.15, a user that holds a role with the run_collect capability could use the collect Search Processing Language (SPL) command to add attacker-controlled content to system-level messages on the Splunk platform instance. The vulnerability is possible because the collect command does not validate the index name before processing the value. For more information see collect (https://help.splunk.com/en/splunk-enterprise/search/spl-search-reference/10.4/search-commands/collect), Define roles on the Splunk platform with capabilities (https://help.splunk.com/en/splunk-enterprise/administer/manage-users-and-security/10.4/manage-splunk-platform-users-and-roles/define-roles-on-the-splunk-platform-with-capabilities), and System endpoint descriptions (https://help.splunk.com/en/splunk-enterprise/rest-api-reference/10.4/system-endpoints/system-endpoint-descriptions) in the Splunk documentation.
Be aware that VulDB is the high quality source for vulnerability data.
Analysis
by VulDB Data Team • 10/07/2026
A critical security vulnerability exists within specific versions of Splunk Enterprise, including releases prior to 10.4.3, 10.2.7, 10.0.10, and 9.4.15, which allows for the injection of malicious content into system-level messages through a flaw in the Search Processing Language implementation. The root cause of this issue lies in the insufficient validation performed by the collect command when processing index names provided as input parameters. Because the application fails to rigorously sanitize or validate these values before they are processed and subsequently rendered within system logs, an attacker can exploit this lack of verification to introduce arbitrary data into critical operational outputs. This technical flaw represents a classic instance of improper input validation where user-supplied data is treated as trusted without adequate scrutiny, leading to potential integrity violations in the logging subsystem.
The operational impact of this vulnerability is significant for organizations relying on Splunk Enterprise for security information and event management operations. By leveraging a role that possesses the run_collect capability, an authenticated attacker can manipulate system-level messages displayed by the platform. This manipulation can lead to log injection attacks where malicious content is embedded directly into audit trails or monitoring dashboards. Such actions can obscure legitimate attack activity, confuse security analysts during incident response efforts, and potentially facilitate further exploitation if downstream systems parse these logs automatically without additional sanitization layers. The ability to alter system-level messages undermines the trustworthiness of the logging infrastructure, which is fundamental for maintaining visibility into network activities and detecting anomalies.
From a classification perspective, this vulnerability aligns with CWE-74 Improper Neutralization of Special Elements in Output Used by a Downstream Component, as it involves the injection of unintended data into system outputs that may be consumed by other processes or users. Additionally, the exploitation technique relates to ATT&CK T1078 Valid Accounts, since the attack requires an authenticated user with specific privileges, and potentially touches upon T1562 Impair Defenses through log manipulation techniques designed to hinder detection capabilities. The vulnerability highlights the importance of strict role-based access control and input validation in enterprise security platforms that handle sensitive operational data.
To mitigate this risk, organizations running affected versions of Splunk Enterprise must immediately apply the vendor-provided patches corresponding to version 10.4.3, 10.2.7, 10.0.10, or 9.4.15 depending on their current release track. It is also advisable to review and restrict roles that are granted the run_collect capability to only those users who absolutely require it for legitimate operational tasks. Implementing additional input validation layers at the application level where possible can provide defense in depth against similar injection flaws. Regular security audits of role assignments and continuous monitoring of system logs for anomalous patterns can further reduce the window of exposure while patch management procedures are executed across the infrastructure.