Splunk Enterprise における認証なしのブラインドサーバーサイドリクエストフォージェリ (SSRF)

The SSRF vulnerability in Splunk Enterprise allows an attacker to craft malicious requests that are processed by the Splunk server. Because the attacker can control the destination of these requests, they can potentially access internal resources that are not directly exposed to the internet. The ability to execute REST API calls on behalf of a high-privileged user significantly amplifies the impact. An attacker could leverage this to modify configurations, access sensitive data, or even escalate privileges within the Splunk environment. This could lead to data breaches, system compromise, and disruption of Splunk services. The potential for lateral movement within the network is also a concern, as the attacker could use the SSRF vulnerability to probe and access other internal systems.

Organizations heavily reliant on Splunk Enterprise for security monitoring and data analytics are particularly at risk. Environments with complex internal network topologies and a high degree of inter-system communication are also more vulnerable, as the SSRF vulnerability could be used to map and exploit internal resources. Shared hosting environments where multiple tenants share the same Splunk instance are also at increased risk.

• linux / server: Monitor Splunk logs for unusual outbound HTTP requests, particularly those targeting internal services. Use journalctl -u splunkd to filter for relevant log entries.

journalctl -u splunkd | grep -i 'request: .*://' | grep -v 'localhost'

• generic web: Use curl to test for SSRF by attempting to access internal resources through the Splunk API.

curl -v 'http://<splunk_server>/services/server/rest/system/info' -H 'Host: <internal_server>' 

• splunk: Examine Splunk's internal audit logs for suspicious API calls originating from unexpected sources.

1. 2025-10-01Disclosure

   disclosure

1. 予約済み2024-10-10
2. 公開日2025-10-01
3. 更新日2026-02-26
4. EPSS 更新日2026-03-23

The primary mitigation for CVE-2025-20371 is to upgrade to a patched version of Splunk Enterprise or Splunk Cloud Platform. Specifically, upgrade to Splunk Enterprise 10.0.1 or later, 9.4.4 or later, 9.3.6 or later, 9.2.8 or later, or Splunk Cloud Platform 9.3.2411.109 or later, 9.3.2408.119 or later, and 9.2.2406.122 or later. If immediate upgrade is not possible, consider implementing temporary workarounds such as restricting outbound network access from the Splunk server using a Web Application Firewall (WAF) or proxy to block suspicious requests. Review and tighten Splunk's internal access controls to limit the privileges of high-privileged users. After upgrading, verify the fix by attempting to trigger an SSRF request and confirming that it is blocked.