CVE-2025-20322: Splunk Enterprise · The web application does not, or can not, sufficiently verify whether a well-formed, valid, consistent request was intentionally provided by the user who submitted the request.
Affects Splunk EnterpriseSource CVE Database V5
Not known to be exploited · CVSS 4.3 Medium.
Data as of 25 Oct 2026, 19:02 UTC
- EPSS
- 0.2% chance of exploitation in 30 days – higher than 12% of CVEsExploit Prediction Scoring System: the likelihood attackers will use this flaw soon.
CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:N/A:LExploitation evidence
Disclosed: evidence found.
CVE published 7 Jul 2025
Detectable: no evidence on record.
No public nuclei template indexed
Weaponised: no evidence on record.
No public exploit code indexed in Metasploit or Exploit-DB
Exploited in the wildExploited: no evidence on record.
Not in CISA KEV and no source reports exploitation
Observed by OffSeq MirageSeen by Mirage: no evidence on record.
No attack traffic recorded by OffSeq Mirage sensors
A missing step is not evidence of safety. Sources: cve.org (opens in a new tab), the Metasploit, Exploit-DB and nuclei-templates index as of 2026-10-25.
What to do
Affected software
| Product | Affected | Fixed in |
|---|---|---|
| Splunk Splunk Enterprise | Affected
| Fixed in– |
AI-suggested
1. Upgrade Splunk Enterprise and Splunk Cloud Platform to the fixed versions: 9.4.3 or later, 9.3.5 or later, 9.2.7 or later, and 9.1.10 or later as applicable. This is the most effective mitigation. 2. Implement robust anti-CSRF protections on the Splunk web interface, including the use of anti-CSRF tokens and SameSite cookie attributes to prevent unauthorized cross-origin requests. 3. Enforce strict browser security policies such as Content Security Policy (CSP) and enable multi-factor authentication (MFA) for administrator accounts to reduce the risk of phishing success. 4. Conduct targeted phishing awareness training for administrators and privileged users to reduce the likelihood of social engineering exploitation. 5. Monitor Splunk logs and network traffic for unusual SPL search commands or unexpected rolling restart events to detect potential exploitation attempts early. 6. Restrict administrative access to Splunk web interfaces to trusted networks or VPNs to reduce exposure to external attackers. 7. Regularly review and minimize the number of users with administrator privileges to reduce the attack surface. 8. Consider implementing web application firewalls (WAFs) with custom rules to detect and block suspicious SPL commands or CSRF attempts targeting Splunk.
Description
In Splunk Enterprise versions below 9.4.3, 9.3.5, 9.2.7, and 9.1.10, and Splunk Cloud Platform versions below 9.3.2411.104, 9.3.2408.113, and 9.2.2406.119, an unauthenticated attacker could send a specially-crafted SPL search command that could trigger a rolling restart in the Search Head Cluster through a Cross-Site Request Forgery (CSRF), potentially leading to a denial of service (DoS).<br><br>The vulnerability requires the attacker to phish the administrator-level victim by tricking them into initiating a request within their browser. The attacker should not be able to exploit the vulnerability at will.<br><br>See [How rolling restart works](https://docs.splunk.com/Documentation/Splunk/9.4.2/DistSearch/RestartSHC) for more information.