Advisory · CVE-2026-76291
Splunk Enterprise scheduled searches skip the risky SPL safeguards applied to normal searches
Splunk Enterprise below 10.4.4, 10.2.8, 10.0.11 and 9.4.16 does not apply SPL safeguards for risky commands to scheduled searches, so a user with the schedule_search capability can run risky SPL that can disclose or alter Splunk data or disrupt availability. CVSS 3.1 8.8.
- Vendor
- Splunk
- Product
- Splunk Enterprise
- Identifier / CWE
- CVE-2026-76291
CWE-284 - Action timing
- Immediate
Explain it like I’m five
Splunk checks dangerous search commands when you run them by hand, but forgot to check the same commands when they run on a schedule, so a low-privilege user can set a timer and let the dangerous command run unchecked.
- 01User holds schedule_search
A user whose role includes the schedule_search capability prepares a search that uses a risky SPL command.
- 02Search is scheduled
The user saves the search as a scheduled search instead of running it interactively.
- 03Scheduler skips safeguards
Per Splunk, the search scheduler does not apply the SPL safeguards for risky commands to scheduled searches.
- 04Risky SPL runs
The scheduled search executes the risky command with the effects Splunk describes: data can be disclosed or altered, or Splunk availability disrupted.
What happened
Splunk disclosed CVE-2026-76291 in advisory SVD-2026-1007: in Splunk Enterprise versions below 10.4.4, 10.2.8, 10.0.11 and 9.4.16, a user that holds a role with the schedule_search capability could bypass the expected safeguards in the scheduled search workflow and run risky Search Processing Language (SPL) commands that disclose or alter Splunk Enterprise data or disrupt Splunk Enterprise availability. Splunk states the vulnerability is possible because the Splunk Enterprise search scheduler does not apply SPL safeguards for risky commands to scheduled searches. The CVSS 3.1 score is 8.8, with network attack vector, low complexity, low privileges required, and no user interaction.
Per Splunk, the fixed releases are 10.4.4, 10.2.8, 10.0.11 and 9.4.16 or higher for the branch in use. Splunk lists no mitigations or workarounds for this CVE in the advisory, so upgrading is the stated remedy. Review which roles carry schedule_search before and after the upgrade, because that capability is the entry condition for this flaw.
What to do
- Inventory Splunk Enterprise deployments and note the version and branch of each, including search heads and search head clusters.
- Upgrade affected installations to 10.4.4, 10.2.8, 10.0.11 or 9.4.16 or higher for the branch in use, using the Splunk advisory guidance; Splunk lists no workaround for this CVE.
- Audit which roles and users hold the schedule_search capability and remove it where it is not needed.
- Review scheduled searches created or changed by low-privilege users for risky SPL commands, and hunt for scheduled searches that disclosed, altered or deleted data or disrupted availability.
- Verify the deployed version on every search head after updating, including cluster members and standby systems.
Management note
Splunk holds the security telemetry itself, so a safeguard bypass that lets a low-privilege user run risky SPL is a trust problem for the whole monitoring stack. Patch on the emergency ring and audit scheduled searches, not just versions.