EUVD-2026-62961
GHSA-7f6r-w4cf-54v3
Severity by source
AV:N/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H
Network-accessible via Splunk API/UI, but AC:H because attacker must also control an accessible model file; PR:L for mandatory schedule_search role; scope unchanged within Splunk.
Primary rating from Vendor (cisco).
CVSS VectorVendor: cisco
Lifecycle Timeline
3DescriptionCVE.org
In Splunk AI Toolkit versions below 6.0.0, a user that holds a role with the schedule_search capability could cause a scheduled search to load and deserialize a model file through the apply search command. The improper access control is possible because Splunk AI Toolkit does not mark the apply search command as risky. For more information see Troubleshoot the AI Toolkit (https://help.splunk.com/en/splunk-enterprise/apply-machine-learning/use-ai-toolkit/5.7.3/troubleshooting-the-ai-toolkit/troubleshoot-the-ai-toolkit) in the Splunk documentation.
AnalysisAI
Improper access control in Splunk AI Toolkit versions below 6.0.0 allows an authenticated user holding the schedule_search capability to deserialize arbitrary model files by invoking the apply search command via a scheduled search. Because the toolkit does not designate apply as a risky command, Splunk's built-in risky-command access controls are never triggered, enabling privilege escalation beyond what the role should permit. A vendor-released patch exists (version 6.0.0); no public exploit or CISA KEV listing has been identified at time of analysis.
Technical ContextAI
Splunk's search processing language exposes an apply command within the AI Toolkit that loads serialized machine learning model files and applies them to search results. Splunk Enterprise uses a risky command classification framework to gate sensitive search operations behind additional access controls; commands not flagged as risky bypass these gates. CWE-269 (Improper Privilege Management) identifies the root cause: the apply command was omitted from the risky-command list despite its ability to trigger deserialization of potentially attacker-influenced files. Deserialization vulnerabilities can yield arbitrary code execution if an attacker can supply or manipulate the file being deserialized. The affected product is identified by CPE cpe:2.3:a:splunk:splunk_ai_toolkit:*:*:*:*:*:*:*:*, covering the 5.7.x series up to but not including 6.0.0, as confirmed by EUVD-2026-62961.
RemediationAI
Upgrade Splunk AI Toolkit to version 6.0.0 or later per vendor advisory SVD-2026-0808 at https://advisory.splunk.com/advisories/SVD-2026-0808, which resolves the issue by marking the apply command as risky and enabling Splunk's built-in access controls to gate its use. As a compensating control prior to patching, administrators should audit all Splunk roles and remove the schedule_search capability from any accounts that do not require it, reducing the population of users who can trigger the vulnerable code path - note that this may impact legitimate scheduled search workflows. Additionally, restricting write access to model file storage directories limits attacker ability to place malicious model files for deserialization. These workarounds reduce exposure but do not close the underlying access control gap; upgrading to 6.0.0 is the definitive remediation.
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 weakness CWE-269 – Improper Privilege Management
View allSame technique Privilege Escalation
View allShare
External POC / Exploit Code
Leaving vuln.today