splunk_cloud_platform

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.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 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.2, 9.3.5, 9.2.7, and 9.1.10 and Splunk Cloud Platform versions below 9.3.2411.104, 9.3.2408.113, and 9.2.2406.119, a low-privileged user that does not hold the "admin" or "power" Splunk roles could create or overwrite [system source type](https://help.splunk.com/en/splunk-enterprise/get-started/get-data-in/9.2/configure-source-types/create-source-types) configurations by sending a specially-crafted payload to the `/servicesNS/nobody/search/admin/sourcetypes/` REST endpoint on the Splunk management port.

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.104, 9.3.2408.113, and 9.2.2406.119, an unauthenticated attacker could send a specially-crafted SPL search command that could trigger a rolling restart in the Search Head Cluster through a Cross-Site Request Forgery (CSRF), potentially leading to a denial of service (DoS).<br><br>The vulnerability requires the attacker to phish the administrator-level victim by tricking them into initiating a request within their browser. The attacker should not be able to exploit the vulnerability at will.<br><br>See [How rolling restart works](https://docs.splunk.com/Documentation/Splunk/9.4.2/DistSearch/RestartSHC) for more information.

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.104, 9.3.2408.114, and 9.2.2406.119, an unauthenticated attacker can send a specially-crafted SPL search that could change the membership state in a Splunk Search Head Cluster (SHC) through a Cross-Site Request Forgery (CSRF), potentially leading to the removal of the captain or a member of the SHC.<br><br>The vulnerability requires the attacker to phish the administrator-level victim by tricking them into initiating a request within their browser. The attacker should not be able to exploit the vulnerability at will.

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.107, 9.3.2408.117, and 9.2.2406.121, a low-privileged user that does not hold the "admin" or "power" Splunk roles could craft a malicious payload through the `User Interface - Views` configuration page that could potentially lead to a denial of service (DoS).The user could cause the DoS by exploiting a path traversal vulnerability that allows for deletion of arbitrary files within a Splunk directory. The vulnerability requires the low-privileged user to phish the administrator-level victim by tricking them into initiating a request within their browser. The low-privileged user should not be able to exploit the vulnerability at will.