Loading vulnerability…
Blind SSRF in Splunk Enterprise and Splunk Cloud Platform
CVE-2025-20371 is a high-severity blind server-side request forgery vulnerability in Splunk Enterprise and Splunk Cloud Platform. In affected versions, an unauthenticated attacker can cause the Splunk server to issue HTTP requests to unintended destinations. Available reporting indicates the issue is associated with Distributed Search Peers and insufficient validation or restriction of user-controlled request targets, enabling the server to send outbound requests on the attacker’s behalf. Under the documented exploitation conditions, the forged requests may be performed in the security context of an authenticated high-privileged user, potentially allowing REST API actions against internal Splunk services or other reachable internal resources. Because the SSRF is blind, the attacker does not directly receive the response body, but can still induce server-side interactions with internal or external endpoints.
What it means and what to do now: patch path, interim mitigations, and the assume-compromise checklist.
What an attacker gets, and what they’ve been doing with it.
Successful exploitation can let an unauthenticated attacker use the Splunk server as a pivot to reach arbitrary destinations that are accessible from the server. The most significant consequence is the ability to trigger REST API calls as an authenticated high-privileged user, which can expose sensitive internal resources, affect Splunk administrative functions, and interfere with security monitoring operations. Even without direct response visibility, blind SSRF can still support internal network reconnaissance, interaction with internal services, and abuse of trust relationships available to the Splunk instance.
If you can’t patch tonight, do this now.
If immediate patching is not possible, reduce exposure by setting enableSplunkWebClientNetloc to false, as this setting is identified as a prerequisite for exploitation in available reporting. Disabling Splunk Web where operationally feasible further reduces attack surface. Additional defensive measures include restricting assignment and use of high-privilege roles, limiting browser-driven administrative workflows where possible, and constraining outbound network access from Splunk systems to only required destinations to reduce SSRF utility.
Patch, then assume compromise.
Upgrade Splunk Enterprise to a fixed release: 10.0.1 or later, 9.4.4 or later, 9.3.6 or later, or 9.2.8 or later, depending on the deployed branch. For Splunk Cloud Platform, ensure the environment is updated to fixed builds including 9.3.2411.109 or later, 9.3.2408.119 or later, or 9.2.2406.122 or later, as applicable. Splunk Cloud Platform instances are reported to be patched by the vendor, but customers should verify patch status through normal support and maintenance channels.
No public exploits tracked yet. Mallory keeps watching.
Products and vendors Mallory has correlated with this vulnerability. Open in Mallory to drill down to specific CPE configurations and version ranges.
13 sources tracked across advisories, community write-ups, and news. New activity surfaces here as Mallory finds it.