Server-Side Request Forgery (SSRF) through the Report Notification REST API in Splunk Secure Gateway
- Published
- Last modified
- Where the record stands: published, rejected by its publisher, or superseded by another id.What do these mean? →
- published
- Whether CISA lists it in its Known Exploited Vulnerabilities catalog: proof that attackers are using it.What do these mean? →
- Not listed in CISA KEV
- Fix
- Fixed in 10.4.2, 10.2.6, 10.0.9, 9.4.14, 3.10.9, and 2 more
- Whether working attack code is public (Exploit-DB, Metasploit, Nuclei or GitHub). Public code makes attacks easier.What do these mean? →
- None on Exploit-DB, Metasploit or GitHub
- Exploitation: none
- Automatable: no
- Technical impact: total
Summary
In Splunk Enterprise versions below 10.4.2, 10.2.6, 10.0.9, and 9.4.14, and Splunk Secure Gateway versions below 3.10.9, 3.9.23, and 3.8.70, a user who does not hold the "admin" or "power" Splunk roles could use crafted report notification data to cause Splunk Secure Gateway to send a request to the Splunk Enterprise Representational State Transfer (REST) API using a system-level session token and modify the Splunk platform configuration. The user could then obtain a session token without a password and use it to access all relevant data and affect system integrity. The vulnerability is possible because Splunk Secure Gateway does not validate decoded report notification identifiers before using them to construct requests to the Splunk Enterprise REST API.
Timeline
- CVE published
- CISA SSVC assessment
Exploitation: none · Automatable: no · Technical impact: total
- Record last updated
Affected versions
- Splunk Splunk Enterprise
From 10.4 · fixed in 10.4.2; From 10.2 · fixed in 10.2.6; From 10.0 · fixed in 10.0.9; From 9.4 · fixed in 9.4.14
- Splunk Splunk Secure Gateway
From 3.10 · fixed in 3.10.9; From 3.9 · fixed in 3.9.23; From 3.8 · fixed in 3.8.70