In Splunk Enterprise versions below 10.2.4, 10.0.7, 9.4.12, and 9.3.13, Splunk Cloud Platform versions below 10.3.2512.12, 10.2.2510.14, 10.1.2507.22, and 9.3.2411.132, and Splunk Secure Gateway versions below 3.10.6, 3.9.20, and 3.8.67, a low-privileged user that does not hold the 'admin' or 'power' Splunk roles could perform a Remote Code Execution (RCE) through the Splunk Secure Gateway app.<br><br>The Remote Code Execution is possible because of unsafe deserialization of App Key Value Store (KV Store) data through the ‘jsonpickle’ Python library, which reconstructs arbitrary Python objects from specially crafted JavaScript Object Notation (JSON) without adequate validation.
In Splunk Enterprise versions below 10.2.4, 10.0.7, 9.4.12, and 9.3.13, and Splunk Cloud Platform versions below 10.4.2604.3, 10.3.2512.12, 10.2.2510.14, 10.1.2507.22, and 9.3.2411.132, a low-privileged user that does not hold the "admin" or "power" Splunk roles could send server-side requests to arbitrary internal destinations through the Dashboard Studio PDF export feature.
The vulnerability exists because the trusted-domain validation uses a prefix match that can be bypassed with attacker-controlled subdomains (for example, docs.splunk.com.evil.com), and because the PDF export service follows HTTP redirects automatically without re-validating each redirect target against the allowlist.
In Splunk Enterprise versions below 10.2.4, 10.0.7, 9.4.12, and 9.3.13, and Splunk Cloud Platform versions below 10.3.2512.13, 10.2.2510.15, 10.1.2507.23, and 9.3.2411.132, a low-privileged user that does not hold the 'admin' or 'power' Splunk roles could craft a malicious classic dashboard that exfiltrates sensitive data to an external server when a higher-privileged user views it, bypassing the external content restriction through a Cascading Style Sheets (CSS) injection.<br><br>The Trusted Domains security check does not fully validate inline style attribute values, which can allow for outbound requests to untrusted domains and credential exfiltration when a victim views a crafted dashboard.
In Splunk Enterprise versions below 10.2.2, 10.0.5, 9.4.11, and 9.3.12, and Splunk Cloud Platform versions below 10.4.2603.1, 10.3.2512.9, 10.2.2510.11, 10.1.2507.21, 10.0.2503.13, and 9.3.2411.129, a low-privileged user that does not hold the ‘admin’ or ‘power’ Splunk roles could cause a Denial of Service by exploiting the `coldToFrozen.sh` script in the `splunk_archiver` app to rename critical Splunk directories, making the instance non-functional.<br><br>The Denial of Service is possible because of missing input validation in the `coldToFrozen.sh` script, which accepts arbitrary file paths and renames them without restricting operations to safe directories.
In Splunk Enterprise versions below 10.2.2, 10.0.5, 9.4.10, and 9.3.11, and Splunk Cloud Platform versions below 10.4.2603.0, 10.3.2512.6, 10.2.2510.10, 10.1.2507.20, 10.0.2503.13, and 9.3.2411.127, a user who holds a role that contains the high-privilege capability `edit_user`could create a specially crafted username that includes a null byte or a non-UTF-8 percent-encoded byte due to improper input validation.<br><br>This could lead to inconsistent conversion of usernames into a proper format for storage and account management inconsistencies, such as being unable to edit or delete affected users.
In Splunk Enterprise versions below 10.2.2, 10.0.5, 9.4.10, and 9.3.11, and Splunk Cloud Platform versions below 10.4.2603.0, 10.3.2512.6, 10.2.2510.10, 10.1.2507.19, 10.0.2503.13, and 9.3.2411.127, a low-privileged user that does not hold the `admin` or `power` Splunk roles, has write permission on the app, and does not hold the high-privilege capability `accelerate_datamodel`, could turn on or off Data Model Acceleration due to improper access control.
In Splunk Enterprise versions below 10.2.1, 10.0.5, 9.4.10, and 9.3.11, and Splunk Cloud Platform versions below 10.4.2603.0, 10.3.2512.5, 10.2.2510.9, 10.1.2507.19, 10.0.2503.13, and 9.3.2411.127, a low-privileged user that does not hold the `admin` or `power` Splunk roles could potentially perform a Remote Code Execution (RCE) by uploading a malicious file to the `$SPLUNK_HOME/var/run/splunk/apptemp` directory due to improper handling and insufficient isolation of temporary files within the `apptemp` directory.
In Splunk Enterprise versions below 10.2.0, 10.0.3, 9.4.9, and 9.3.9, and Splunk Cloud Platform versions below 10.2.2510.4, 10.1.2507.15, 10.0.2503.11, and 9.3.2411.123, a low-privileged user who does not hold the "admin" or "power" Splunk roles could craft a malicious payload when creating a View (Settings - User Interface - Views) at the `/manager/launcher/data/ui/views/_new` endpoint leading to a Stored Cross-Site Scripting (XSS) through a path traversal vulnerability. This could result in execution of unauthorized JavaScript code in the browser of a user.
The vulnerability requires the attacker to phish the victim by tricking them into initiating a request within their browser. The authenticated user should not be able to exploit the vulnerability at will.
In Splunk Enterprise versions below 10.2.0, 10.0.4, 9.4.9, and 9.3.10, and Splunk Cloud Platform versions below 10.2.2510.5, 10.0.2503.12, 10.1.2507.16, and 9.3.2411.124, a user who holds a role that contains the high-privilege capability `edit_cmd` could execute arbitrary shell commands using the `unarchive_cmd` parameter for the `/splunkd/__upload/indexing/preview` REST endpoint.
In Splunk Enterprise versions below 10.2.0, 10.0.3, 9.4.9, and 9.3.10, and Splunk Cloud Platform versions below 10.2.2510.5, 10.1.2507.16, 10.0.2503.11, and 9.3.2411.123, a low-privileged user that does not hold the "admin" or "power" Splunk roles could access the `/splunkd/__raw/servicesNS/-/-/configs/conf-passwords` REST API endpoint, which exposes the hashed or plaintext password values that are stored in the passwords.conf configuration file due to improper access control. This vulnerability could allow for the unauthorized disclosure of sensitive credentials.