Attack ChainAIDerived
Hypothetical attack flow derived from CVE metadata – not a confirmed exploit chain
-
AccessHost malicious page with forged GET
-
DeliveryLure list_deployment_server user to page
-
ExploitBrowser submits request with victim session
-
ExecutionCSRF bypasses token check on endpoint
-
PersistInjected SPL runs as splunk-system-user
-
ImpactExfiltrate stored credentials and indexed data
Vulnerability Assessment
| Weakness |
CWE
OWASP Top 10:2025
A01:2025 - Broken Access Control
ASVS 5.0
V3 - Web Frontend Security Anti-CSRF tokens, SameSite cookies
MITRE ATT&CK
1 technique across 1 tactic: Initial Access The technique list with ATT&CK links and the kill-chain view is part of the Basic plan and up. |
| Exploitation Conditions | Exploitation requires a victim who is authenticated to Splunk Web with an active session and holds a role granting the list_deployment_server capability, and who is induced (UI:R) to load attacker-controlled content while that session is live. The specific enabling defect is that Deployment Server endpoints in Splunk Web do not validate CSRF tokens on GET requests and do not neutralize caller-supplied input before placing it into an SPL search. Limiting factors: the target instance must be running Splunk Web with Deployment Server in use; the tricked user must have the list_deployment_server capability (typically admins/deployment operators, not arbitrary users); and the attacker must succeed at the social-engineering step to trigger the forged request - the attacker themselves needs no Splunk credentials (PR:N). |
| Impact | The CVSS 3.1 vector (AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:L, base 8.3 High) shows a network-reachable, low-complexity attack that needs no attacker privileges (PR:N) but does require user interaction (UI:R) - consistent with CSRF, where the attacker rides a victim's authenticated session rather than authenticating themselves. The practical limiter is meaningful: the victim must be an authenticated user who holds the list_deployment_server capability, i.e. typically an administrator or deployment operator, so this is not a mass, any-user attack. EPSS is not provided in the input, and the CVE is not in CISA KEV, so there is no evidence of active exploitation; likewise no POC is referenced, so exploitation status is 'no public exploit identified at time of analysis.' The high confidentiality/integrity impact (credential and data theft, arbitrary SPL) makes this a genuine priority for organizations running Deployment Server, but the requirement to socially engineer a privileged, currently-logged-in user tempers the likelihood of opportunistic mass exploitation relative to the raw 8.3 score. No signals in the input conflict; the main gap is the absence of EPSS/KEV/POC data to gauge real-world exploitation velocity. |
| Exploit ScenarioDerived | An attacker crafts a malicious web page containing a forged GET request (e.g. an auto-loading image or link) targeting a vulnerable Deployment Server endpoint with injected SPL, then lures a Splunk operator who holds the list_deployment_server capability to visit it while logged into Splunk Web. The victim's browser silently submits the request with their session, causing the injected search to run as splunk-system-user and exfiltrate stored credentials or indexed data. No public POC is referenced, but the low attack complexity and reliance on a simple forged GET make weaponization straightforward for a motivated attacker. |
Get an e-mail when this CVE is exploited, patched or re-scored. Free account.
Alert meAnalysisAIv1 – Jul 15, 2026
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.
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.
Affected VersionsENISA
Affected Packages
Source: OSV (Open Source Vulnerabilities)
Affects your stack
Affects 2 packages in euvd
Checking this CVE against your own stacks and servers is part of the Basic plan and up.
Technical ContextAI · show details
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.
Know when Splunk gets its next vulnerability
- Watch products and get an email when something new is published
- Check this CVE against your own stack and servers
- Exploit and PoC references, threat intelligence from 22 sources
No credit card · 7-day full trial
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
2DescriptionCVE.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.
Executive ViewAI
Splunk Enterprise and Cloud Platform users running versions prior to 10.4.1, 10.2.5, 10.0.8, or 9.4.13 face a credential and data exposure risk: a CSRF-injection vulnerability in Deployment Server endpoints allows attackers to manipulate authenticated users into executing unauthorized searches, compromising stored credentials and sensitive indexed data.
No vendor-released patch identified at time of analysis. Interim mitigations: restrict network access to Deployment Server endpoints to trusted administrative networks via firewall or WAF; minimize and audit list_deployment_server capability assignments; enforce multi-factor authentication for all Splunk administrative accounts; continuously monitor search audit logs for anomalous searches executed by system-level accounts; consider temporarily disabling Deployment Server functionality if operationally feasible; review and restrict who can send messages or emails to users with deployment server access to reduce social engineering risk.
Threat Intelligence Overview
How this decision was reached
The engine reads each signal below and applies a fixed list of rules from top to bottom. The first rule that matches sets the recommended action – like a statement, every line is shown.
What every action level means
SSVC AssessmentENISA
Priority Score
Attack Technique
Cross-Site Request Forgery exploits the automatic credential inclusion behavior of web browsers.
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
curl < 7.84.0 supports "chained" HTTP compression algorithms, meaning that a serverresponse can be compressed multiple t
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 curl < 7.84.0 saves cookies, alt-svc and hsts data to local files, it makes the operation atomic by finalizing the
SQLite 1.0.12 through 3.39.x before 3.39.2 sometimes allows an array-bounds overflow if billions of bytes are used in a
A vulnerability exists in curl <7.87.0 HSTS check that could be bypassed to trick it to keep using HTTP. Rated high seve
When doing HTTP(S) transfers, libcurl might erroneously use the read callback (`CURLOPT_READFUNCTION`) to ask for data t
EUVD-2026-44737
GHSA-hxgj-4vg5-fpww
NVD
CVE.org
EPSS
Vulnrichment
VulDB
Exploit-DB