EUVD-2026-44737
GHSA-hxgj-4vg5-fpww
Severity by source
AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:L
CSRF uses the victim's session so PR:N with UI:R; network-reachable Web endpoint and simple forged GET give AV:N/AC:L; credential and data access yield C:H/I:H with limited A:L.
Primary rating from Vendor (cisco).
CVSS VectorVendor: cisco
Lifecycle Timeline
3DescriptionCVE.org
In Splunk Enterprise versions below 10.4.1, 10.2.5, 10.0.8, and 9.4.13, and Splunk Cloud Platform versions below 10.5.2605.0, 10.4.2604.7, 10.3.2512.16, 10.2.2510.18, and 10.1.2507.24, an attacker could trick a user that holds a role with the list_deployment_server capability into running arbitrary Search Processing Language (SPL) searches on their behalf as splunk-system-user, allowing for access to stored credentials and indexed data.<br><br>The vulnerability is possible because Deployment Server endpoints in Splunk Web do not validate Cross-Site Request Forgery (CSRF) tokens on GET requests, and caller-supplied input is not correctly neutralized before it is placed into an SPL search.
AnalysisAI
Cross-Site Request Forgery combined with SPL injection in Splunk Enterprise (below 10.4.1, 10.2.5, 10.0.8, 9.4.13) and Splunk Cloud Platform lets an attacker trick a logged-in user holding the list_deployment_server capability into unknowingly executing attacker-controlled Search Processing Language searches as the privileged splunk-system-user, exposing stored credentials and indexed data. The flaw stems from Deployment Server endpoints in Splunk Web accepting unvalidated GET requests without CSRF token checks and failing to neutralize caller input before it reaches an SPL search. No public exploit has been identified at time of analysis and it is not listed in CISA KEV.
Technical ContextAI
The affected component is Splunk Web's Deployment Server, the management-plane feature used to centrally distribute configurations and apps to Splunk forwarders and instances. The root cause is CWE-352 (Cross-Site Request Forgery): the Deployment Server endpoints do not validate anti-CSRF tokens on HTTP GET requests, so a request forged by a malicious page is treated as legitimate when the victim's browser carries their Splunk session. This is compounded by an injection weakness - caller-supplied input is not correctly neutralized before being embedded into an SPL query - turning the CSRF into a vehicle for arbitrary SPL execution. Because the injected search runs as the internal splunk-system-user identity, it inherits broad access to secret storage (stored credentials) and to indexed data across the deployment. Per the CPE data, both cpe:2.3:a:splunk:splunk_enterprise and cpe:2.3:a:splunk:splunk_cloud_platform are affected.
RemediationAI
Upgrade to a fixed release: Splunk Enterprise 10.4.1, 10.2.5, 10.0.8, or 9.4.13 (on the respective maintained branch); Splunk Cloud Platform is remediated in 10.5.2605.0, 10.4.2604.7, 10.3.2512.16, 10.2.2510.18, and 10.1.2507.24, which Splunk applies to managed Cloud tenants. Consult the vendor advisory at https://advisory.splunk.com/advisories/SVD-2026-0702 for branch-specific guidance. Where immediate patching is not possible, reduce exposure by restricting the list_deployment_server capability to the minimum set of roles/users (removing it from broadly-assigned roles), which directly shrinks the pool of viable CSRF victims but may hamper legitimate deployment-server visibility; instruct privileged operators to avoid browsing untrusted sites while authenticated to Splunk Web and to log out of admin sessions when idle; and place Splunk Web behind network access controls (VPN/IP allowlists) so the management UI is not broadly reachable, at the cost of admin convenience. Patch status: vendor-released patch - Splunk Enterprise 10.4.1 / 10.2.5 / 10.0.8 / 9.4.13.
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.
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
A vulnerability in input validation exists in curl <8.0 during communication using the TELNET protocol may allow an atta
Same weakness CWE-352 – Cross-Site Request Forgery (CSRF)
View allShare
External POC / Exploit Code
Leaving vuln.today