CVE-2026-76253 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, a user that holds a role with the schedule_search capability could run arbitrary Search Processing Language (SPL) commands with the highest level of system privilege and read every credential stored in the credential store, which can allow for disclosure and modification of all relevant data and affect system integrity and availability. The vulnerability is possible because scheduled search alert action configuration does not properly restrict user-specific alert action settings before the search scheduler runs alert actions. For more information see Create scheduled alerts (https://help.splunk.com/en/splunk-enterprise/alert-and-respond/alerting-manual/9.3/create-alerts/create-scheduled-alerts), Set up alert actions (https://help.splunk.com/en/splunk-enterprise/alert-and-respond/alerting-manual/9.3/configure-alert-actions/set-up-alert-actions), 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 Configuration file precedence (https://help.splunk.com/en/splunk-enterprise/administer/admin-manual/10.2/administer-splunk-enterprise-with-configuration-files/configuration-file-precedence) in the Splunk documentation.
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 08/20/2026
Splunk Enterprise versions prior to 10.4.2, 10.2.6, 10.0.9, and 9.4.14 contain a critical privilege escalation vulnerability within its scheduled search alert action configuration mechanism. This flaw allows any user possessing the schedule_search capability to execute arbitrary Search Processing Language commands with elevated system privileges. The core technical deficiency lies in the failure of the application to properly restrict or validate user-specific alert action settings prior to their execution by the internal search scheduler. Because the scheduler operates under a high-privilege context, it processes these configurations without adequate isolation from the requesting user's permissions, effectively bypassing standard access control checks that would normally limit what data and commands an authenticated user can interact with.
The operational impact of this vulnerability is severe, as it enables unauthorized actors to read every credential stored in Splunk’s internal credential store. These credentials are often used for connecting to various external systems, databases, and services monitored by the platform. By extracting these secrets, attackers gain the ability to disclose sensitive information, modify critical data across integrated environments, and potentially compromise system integrity and availability. This level of access effectively grants an attacker full control over the Splunk infrastructure and any connected assets that rely on those stored credentials for authentication or communication.
From a classification perspective, this vulnerability aligns with CWE-269 Improper Privilege Management, specifically where a user is able to perform actions beyond their assigned role due to flawed authorization logic in scheduled tasks. It also relates to CWE-732 Incorrect Permission Assignment for Critical Resource, as the credential store and associated data are exposed without proper access restrictions. In terms of adversary behavior, this exploit maps directly to MITRE ATT&CK technique T1098.004 SSH Authorized Keys Manipulation if used for lateral movement, but more accurately reflects T1528 Steal Application Access Token or T1556 Modify Authentication Process when targeting the credential store itself. The ability to run arbitrary SPL commands with highest privilege also touches upon T1059 Command and Scripting Interpreter execution within a privileged context.
Mitigation strategies require immediate patching of all affected Splunk Enterprise instances to versions 10.4.2, 10.2.6, 10.0.9, or 9.4.14 where this logic error has been corrected. Organizations should also audit their role definitions to ensure that the schedule_search capability is granted only to trusted administrative accounts rather than broad user groups. Implementing strict input validation on alert action configurations and enforcing principle of least privilege for scheduled task execution contexts are essential defensive measures until patches can be applied. Regular review of configuration file precedence rules helps prevent misconfigurations that could exacerbate such vulnerabilities in the future.