Severity by source
AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
Network-accessible via MLTK interface (AV:N), 'power' role sufficient (PR:L), and server-side RCE escapes Splunk's application boundary to the host OS (S:C).
Primary rating from Vendor (cisco).
CVSS VectorVendor: cisco
Lifecycle Timeline
3DescriptionCVE.org
In Splunk AI Toolkit versions below 6.0.0, a user who holds the "power" Splunk role could execute arbitrary code on the Splunk server by loading a model file containing crafted sparse matrix data. The deserialization of untrusted data is possible because a model codec in Splunk AI Toolkit deserializes sparse matrix data without guarding against embedded pickle content. For more information see Troubleshoot the Splunk Machine Learning Toolkit (https://help.splunk.com/en/splunk-cloud-platform/apply-machine-learning/machine-learning-toolkit-user-guide/5.5.0/troubleshooting-mltk/troubleshoot-the-splunk-machine-learning-toolkit) in the Splunk documentation.
AnalysisAI
Arbitrary code execution in Splunk AI Toolkit below 6.0.0 is achievable by any user holding the Splunk 'power' role, through loading a crafted model file that embeds malicious pickle payloads inside sparse matrix data. The toolkit's model codec deserializes this data without sanitizing or restricting the embedded pickle content, granting the attacker code execution as the Splunk server process. No public exploit or CISA KEV listing has been identified at time of analysis, but the RCE impact with a low-privilege network vector makes this a high-priority patch target for any Splunk deployment running the AI or Machine Learning Toolkit.
Technical ContextAI
CWE-502 (Deserialization of Untrusted Data) is the root cause. Python's pickle format is inherently unsafe for untrusted input, as it executes arbitrary Python bytecode during deserialization. The Splunk AI Toolkit (MLTK) uses a model codec that processes sparse matrix data - likely stored in a format such as NumPy's .npz or SciPy's sparse matrix formats - which internally can contain pickle-serialized objects. The toolkit fails to validate or restrict the deserialization path, allowing crafted sparse matrix files to smuggle pickle payloads that execute on the server. Affected product is identified by CPE cpe:2.3:a:splunk:splunk_ai_toolkit:*:*:*:*:*:*:*:* covering all versions prior to 6.0.0, with EUVD-2026-62960 confirming the 5.7-below-6.0.0 version range as vulnerable.
RemediationAI
Upgrade Splunk AI Toolkit to version 6.0.0 or later, which is confirmed by vendor advisory SVD-2026-0808 (https://advisory.splunk.com/advisories/SVD-2026-0808) to resolve the unsafe deserialization. The exact patch version is stated as 6.0.0 per EUVD data; verify the release notes at the vendor advisory for confirmation. If immediate upgrade is not possible, restrict assignment of the Splunk 'power' role to the minimum necessary users, as this limits the attacker population - note that this does not eliminate the vulnerability but reduces exposure. Additionally, audit and restrict which users can load or import model files within the MLTK interface, and avoid loading model files from untrusted or external sources. No alternative codec-level workaround is described in available data.
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-502 – Deserialization of Untrusted Data
View allShare
External POC / Exploit Code
Leaving vuln.today
EUVD-2026-62960
GHSA-wmwx-pqh3-xv86