Severity by source
AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:N
Splunk is network-accessible; 'power' role is a low-privilege authenticated requirement (PR:L); full SPL execution enables high confidentiality and integrity impact with no availability disruption.
Primary rating from Vendor (cisco).
CVSS VectorVendor: cisco
Lifecycle Timeline
3DescriptionCVE.org
In Splunk AI Toolkit versions below 6.0.1, a user who holds the "power" Splunk role could modify app-provided scheduled searches to run arbitrary Search Processing Language (SPL) using the permissions of the search owner, which could allow access to all relevant data and affect system integrity. The vulnerability is possible because Splunk AI Toolkit gives the "power" Splunk role permission to modify scheduled searches that run using the permissions of the search owner.
AnalysisAI
Splunk AI Toolkit before version 6.0.1 allows authenticated users holding the built-in 'power' role to modify app-provided scheduled searches, which execute SPL under the permissions of the search owner rather than the modifying user. By injecting arbitrary SPL into such searches, a 'power' role user can access all data visible to the search owner and alter system integrity - effectively escalating privileges beyond their authorization level. No public exploit code or active exploitation has been identified at time of analysis.
Technical ContextAI
Splunk AI Toolkit (CPE: cpe:2.3:a:splunk:splunk_ai_toolkit:*:*:*:*:*:*:*:*) is an add-on for the Splunk platform providing AI and machine learning capabilities, including scheduled searches for automated data analysis. Splunk's scheduled search design intentionally runs searches under the permissions of the search owner to enable data sharing across privilege levels - a legitimate feature. CWE-732 (Incorrect Permission Assignment for Critical Resource) describes the root cause: the toolkit incorrectly grants the 'power' built-in Splunk role write access to these app-provided scheduled searches. The 'power' role sits above 'user' but below 'admin' and is commonly assigned to analysts and power users who need enhanced search and reporting capabilities. Because search modification is permitted but execution context is that of the higher-privileged owner, the permission boundary between role capability and execution scope is violated, enabling privilege escalation through SPL injection.
RemediationAI
Upgrade Splunk AI Toolkit to version 6.0.1 or later, which corrects the incorrect permission assignment for the 'power' role and prevents modification of app-provided scheduled searches. The vendor patch and full advisory are available at https://advisory.splunk.com/advisories/SVD-2026-0808. As a compensating control pending upgrade, administrators should audit all users currently assigned the Splunk 'power' role and restrict that role to fully trusted personnel only; note that revoking the role may impact legitimate analyst workflows dependent on enhanced search capabilities. Additionally, audit the Splunk AI Toolkit's existing scheduled searches for unauthorized SPL modifications - look for searches whose content has changed outside of expected maintenance windows. Restricting network access to the Splunk web interface to trusted internal segments reduces the exposure surface but does not eliminate the risk for insider threats.
The (1) TLS and (2) DTLS implementations in OpenSSL 1.0.1 before 1.0.1g do not properly handle Heartbeat Extension packe
Unauthenticated arbitrary file write in Splunk Enterprise (below 10.2.4 and 10.0.7) and Splunk Cloud Platform (below 10.
curl 7.75.0 through 7.76.1 suffers from a use-after-free vulnerability resulting in already freed memory being used when
In Splunk Enterprise versions below 9.2.2, 9.1.5, and 9.0.10, a low-privileged user that does not hold the admin or powe
In Splunk Enterprise versions below 9.0.7 and 9.1.2, Splunk Enterprise does not safely sanitize extensible stylesheet la
In versions of Splunk Enterprise below 9.0.5, 8.2.11, and 8.1.14, and Splunk Cloud Platform below version 9.0.2303.100,
In Splunk Enterprise versions below 8.2.9, 8.1.12, and 9.0.2, an authenticated user can execute arbitrary code through t
When doing HTTP(S) transfers, libcurl might erroneously use the read callback (`CURLOPT_READFUNCTION`) to ask for data t
When curl < 7.84.0 saves cookies, alt-svc and hsts data to local files, it makes the operation atomic by finalizing the
A cleartext transmission of sensitive information vulnerability exists in curl <v7.88.0 that could cause HSTS functional
When sending data to an MQTT server, libcurl <= 7.73.0 and 7.78.0 could in some circumstances erroneously keep a pointer
A path traversal vulnerability exists in curl <8.0.0 SFTP implementation causes the tilde (~) character to be wrongly re
Same technique Information Disclosure
View allShare
External POC / Exploit Code
Leaving vuln.today
EUVD-2026-62964
GHSA-x8wf-gj49-q42j