| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| In Splunk Enterprise versions below 9.4.1, 9.3.3, 9.2.5, and 9.1.8, and versions below 3.8.38 and 3.7.23 of the Splunk Secure Gateway app on Splunk Cloud Platform, a low-privileged user that does not hold the “admin“ or “power“ Splunk roles could run a search using the permissions of a higher-privileged user that could lead to disclosure of sensitive information.<br><br>The vulnerability requires the attacker to phish the victim by tricking them into initiating a request within their browser. The authenticated low-privileged user should not be able to exploit the vulnerability at will. |
| In Splunk Enterprise versions below 9.3.3, 9.2.5, and 9.1.8, and Splunk Cloud Platform versions below 9.3.2408.104, 9.2.2406.108, 9.2.2403.114, and 9.1.2312.208, a low-privileged user that does not hold the "admin" or "power" Splunk roles could perform a Remote Code Execution (RCE) through a file upload to the "$SPLUNK_HOME/var/run/splunk/apptemp" directory due to missing authorization checks. |
| In Splunk Enterprise versions below 9.4.3, 9.3.5, 9.2.7, and 9.1.10, a user who holds a role that contains the high-privilege capability `edit_scripted` and `list_inputs` capability , could perform a remote command execution due to improper user input sanitization on the scripted input files.<br><br>See [Define roles on the Splunk platform with capabilities](https://docs.splunk.com/Documentation/Splunk/latest/Security/Rolesandcapabilities) and [Setting up a scripted input ](https://docs.splunk.com/Documentation/Splunk/9.4.2/AdvancedDev/ScriptSetup)for more information. |
| In Splunk Enterprise versions below 10.0.1, 9.4.4, 9.3.6 and 9.2.8, and Splunk Cloud Platform versions below 9.3.2411.109, 9.3.2408.119 and 9.2.2406.122, an unauthenticated attacker could trigger a blind server-side request forgery (SSRF) potentially letting an attacker perform REST API calls on behalf of an authenticated high-privileged user. |
| In Splunk Enterprise for Windows versions below 10.0.2, 9.4.6, 9.3.8, and 9.2.10, a new installation of or an upgrade to an affected version can result in incorrect permissions assignment in the Splunk Enterprise for Windows Installation directory. This lets non-administrator users on the machine access the directory and all its contents. |
| In Splunk Universal Forwarder for Windows versions below 10.0.2, 9.4.6, 9.3.8, and 9.2.10, a new installation of or an upgrade to an affected version can result in incorrect permissions assignment in the Universal Forwarder for Windows Installation directory. This lets non-administrator users on the machine access the directory and all its contents. |
| In Splunk Enterprise versions below 10.2.0, 10.0.2, 9.4.7, 9.3.8, and 9.2.11, and Splunk Cloud Platform versions below 10.2.2510.0, 10.1.2507.11, 10.0.2503.9, and 9.3.2411.120, a user of a Splunk Search Head Cluster (SHC) deployment who holds a role with access to the the Splunk _internal index could view the Security Assertion Markup Language (SAML) configurations for Attribute query requests (AQRs) or Authentication extensions in plain text within the conf.log file, depending on which feature is configured. |
| In Splunk Enterprise versions below 10.2.0, 10.0.2, 9.4.7, 9.3.9, and 9.2.11, a user of a Splunk Search Head Cluster (SHC) deployment who holds a role with access to the Splunk `_internal` index could view the `integrationKey`, `secretKey`, and `appSecretKey` secrets, generated by [Duo Two-Factor Authentication for Splunk Enterprise](https://duo.com/docs/splunk), in plain text. |
| In Splunk Enterprise versions below 10.2.0, 10.0.2, 9.4.7, 9.3.9, and 9.2.11, a user of a Splunk Search Head Cluster (SHC) deployment who holds a role with access to the Splunk `_internal` index could view the RSA `accessKey` value from the [<u>Authentication.conf</u> ](https://help.splunk.com/en/splunk-enterprise/administer/admin-manual/10.2/configuration-file-reference/10.2.0-configuration-file-reference/authentication.conf)file, in plain text. |
| In Splunk Enterprise versions below 10.0.2, 10.0.3, 9.4.8, and 9.3.9, a low-privileged user who does not hold the "admin" Splunk role could access the Splunk Monitoring Console App endpoints due to an improper access control. This could lead to a sensitive information disclosure.<br><br>The Monitoring Console app is a bundled app that comes with Splunk Enterprise. It is not available for download on SplunkBase, and is not installed on Splunk Cloud Platform instances. This vulnerability does not affect [Cloud Monitoring Console](https://help.splunk.com/en/splunk-cloud-platform/administer/admin-manual/10.2.2510/monitor-your-splunk-cloud-platform-deployment/introduction-to-the-cloud-monitoring-console). |
| In Splunk Enterprise versions below 10.2.0, 10.0.3, 9.4.5, 9.3.7, and 9.2.9, and Splunk Cloud Platform versions below 10.1.2507.0, 10.0.2503.9, 9.3.2411.112, and 9.3.2408.122, a low-privileged user who does not hold the "admin" or "power" Splunk roles could bypass the SPL safeguards for risky commands when they create a Data Model that contains an injected SPL query within an object. They can bypass the safeguards by exploiting a path traversal vulnerability. |
| In Splunk Enterprise versions below 10.2.0, 10.0.2, 9.4.8, 9.3.9, and 9.2.12, and Splunk Cloud Platform versions below 10.2.2510.3, 10.1.2507.8, 10.0.2503.9, and 9.3.2411.121, a low-privileged user that does not hold the "admin" or "power" Splunk roles could craft a malicious payload into the `realname`, `tz`, or `email` parameters of the `/splunkd/__raw/services/authentication/users/username` REST API endpoint when they change a password. This could potentially lead to a client‑side denial‑of‑service (DoS). The malicious payload might significantly slow page load times or render Splunk Web temporarily unresponsive. |
| In Splunk Enterprise versions below 9.4.4, 9.3.6, and 9.2.8, and Splunk Cloud Platform versions below 9.3.2411.111, 9.3.2408.119, and 9.2.2406.122, a low-privileged user that does not hold the admin or power Splunk roles could access sensitive search results if Splunk Enterprise runs an administrative search job in the background. If the low privileged user guesses the search job’s unique Search ID (SID), the user could retrieve the results of that job, potentially exposing sensitive search results. For more information see https://help.splunk.com/en/splunk-enterprise/search/search-manual/10.0/manage-jobs/about-jobs-and-job-management and https://help.splunk.com/en/splunk-enterprise/search/search-manual/10.0/manage-jobs/manage-search-jobs. |
| In Splunk Enterprise versions below 10.0.1, 9.4.4, 9.3.6, and 9.2.8, and Splunk Cloud Platform versions below 9.3.2411.108, 9.3.2408.118 and 9.2.2406.123, a user who holds a role that contains the high-privilege capability `change_authentication`, could send multiple LDAP bind requests to a specific internal endpoint, resulting in high server CPU usage, which could potentially lead to a denial of service (DoS) until the Splunk Enterprise instance is restarted. See https://help.splunk.com/en/splunk-enterprise/administer/manage-users-and-security/10.0/manage-splunk-platform-users-and-roles/define-roles-on-the-splunk-platform-with-capabilities and https://help.splunk.com/en/splunk-enterprise/administer/manage-users-and-security/10.0/use-ldap-as-an-authentication-scheme/configure-ldap-with-splunk-web#cfe47e31_007f_460d_8b3d_8505ffc3f0dd__Configure_LDAP_with_Splunk_Web for more information. |
| In Splunk Enterprise versions below 9.4.4, 9.3.6, and 9.2.8, and Splunk Cloud Platform versions below 9.3.2411.108, 9.3.2408.118 and 9.2.2406.123, a low privilege user that does not hold the "admin" or "power" Splunk roles could perform an extensible markup language (XML) external entity (XXE) injection through the dashboard tab label field. The XXE injection has the potential to cause denial of service (DoS) attacks. |
| In Splunk Enterprise versions below 9.4.4, 9.3.6, and 9.2.8, and Splunk Cloud Platform versions below 9.3.2411.108, 9.3.2408.118 and 9.2.2406.123, a low privileged user that does not hold the admin or power Splunk roles could craft a malicious payload through the error messages and job inspection details of a saved search. This could result in execution of unauthorized JavaScript code in the browser of a user. |
| In Splunk Enterprise versions below 9.4.4, 9.3.6 and 9.2.8, and Splunk Cloud Platform versions below 9.3.2411.109, 9.3.2408.119 and 9.2.2406.122, a low-privileged user that does not hold the 'admin' or 'power' Splunk roles could craft a malicious payload through the `dataset.command` parameter of the `/app/search/table` endpoint, which could result in execution of unauthorized JavaScript code in the browser of a user. |
| 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.103, 9.3.2408.113, and 9.2.2406.119, the software potentially exposes the search head cluster [splunk.secret](https://help.splunk.com/en/splunk-enterprise/administer/manage-users-and-security/9.4/install-splunk-enterprise-securely/deploy-secure-passwords-across-multiple-servers) key. This exposure could happen if you have a Search Head cluster and you configure the Splunk Enterprise `SHCConfig` log channel at the DEBUG logging level in the clustered deployment. <br><br>The vulnerability would require either local access to the log files or administrative access to internal indexes, which by default only the admin role receives. Review roles and capabilities on your instance and restrict internal index access to administrator-level roles. <br><br>See [Define roles on the Splunk platform with capabilities](https://docs.splunk.com/Documentation/Splunk/latest/Security/Rolesandcapabilities), [Deploy a search head cluster](https://help.splunk.com/en/splunk-enterprise/administer/distributed-search/9.4/deploy-search-head-clustering/deploy-a-search-head-cluster), [Deploy secure passwords across multiple servers](https://help.splunk.com/en/splunk-enterprise/administer/manage-users-and-security/9.4/install-splunk-enterprise-securely/deploy-secure-passwords-across-multiple-servers) and [Set a security key for the search head cluster](https://help.splunk.com/splunk-enterprise/administer/distributed-search/9.4/configure-search-head-clustering/set-a-security-key-for-the-search-head-cluster#id_2c54937a_736c_47b5_9485_67e9e390acfa__Set_a_security_key_for_the_search_head_cluster) for more information. |
| In Splunk Enterprise versions below 9.4.1, 9.3.3, 9.2.5, and 9.1.8, and versions below 3.8.38 and 3.7.23 of the Splunk Secure Gateway app on Splunk Cloud Platform, a low-privileged user that does not hold the “admin“ or “power“ Splunk roles could edit and delete other user data in App Key Value Store (KVStore) collections that the Splunk Secure Gateway app created. This is due to missing access control and incorrect ownership of the data in those KVStore collections.<br><br>In the affected versions, the `nobody` user owned the data in the KVStore collections. This meant that there was no specific owner assigned to the data in those collections. |
| In Splunk Enterprise versions below 9.4.2, 9.3.4 and 9.2.6, and Splunk Cloud Platform versions below 9.3.2411.102, 9.3.2408.111 and 9.2.2406.118, a low-privileged user that does not hold the "admin" or "power" Splunk roles could craft a malicious payload through the pdfgen/render REST endpoint that could result in execution of unauthorized JavaScript code in the browser of a user. |
