In Splunk Enterprise versions below 9.0.5, 8.2.11, and 8.1.14, and in Splunk Cloud Platform versions below 9.0.2303.100, a low-privileged user can perform an unauthorized transfer of data from a search using the ‘copyresults’ command if they know the search ID (SID) of a search job that has recently run.

In Splunk Enterprise versions below 9.0.5, 8.2.11. and 8.1.14, and Splunk Cloud Platform versions below 9.0.2303.100, a low-privileged user who holds the ‘user’ role can see the hashed version of the initial user name and password for the Splunk instance by using the ‘rest’ SPL command against the ‘conf-user-seed’ REST endpoint.

In Splunk Enterprise versions below 9.0.5, 8.2.11, and 8.1.14, and Splunk Cloud Platform versions below 9.0.2303.100, a low-privileged user can trigger an HTTP response splitting vulnerability with the ‘rest’ SPL command that lets them potentially access other REST endpoints in the system arbitrarily.

In versions of Splunk Enterprise below 9.0.5, 8.2.11, and 8.1.14, and Splunk Cloud Platform below version 9.0.2303.100, a low-privileged user who holds a role that has the ‘edit_user’ capability assigned to it can escalate their privileges to that of the admin user by providing specially crafted web requests.

On Splunk Enterprise versions below 9.0.5, 8.2.11, and 8.1.14, an unauthenticated attacker can send specially-crafted messages to the XML parser within SAML authentication to cause a denial of service in the Splunk daemon.

In Splunk Enterprise versions below 8.1.13, 8.2.10, and 9.0.4, a cross-site request forgery in the Splunk Secure Gateway (SSG) app in the ‘kvstore_client’ REST endpoint lets a potential attacker update SSG KV store collections using an HTTP GET request.

In Splunk Enterprise versions below 8.1.13, 8.2.10, and 9.0.4, an improperly-formatted ‘INGEST_EVAL’ parameter in a Field Transformation crashes the Splunk daemon (splunkd).

In Splunk Enterprise versions below 8.1.13, 8.2.10, and 9.0.4, aliases of the ‘collect’ search processing language (SPL) command, including ‘summaryindex’, ‘sumindex’, ‘stash’,’ mcollect’, and ‘meventcollect’, were not designated as safeguarded commands. The commands could potentially allow for the exposing of data to a summary index that unprivileged users could access. The vulnerability requires a higher privileged user to initiate a request within their browser, and only affects instances with Splunk Web enabled.

In Splunk Enterprise versions below 8.1.13, 8.2.10, and 9.0.4, the ‘map’ search processing language (SPL) command lets a search bypass SPL safeguards for risky commands. The vulnerability requires a higher privileged user to initiate a request within their browser and only affects instances with Splunk Web enabled.

In Splunk Enterprise versions below 8.1.13, 8.2.10, and 9.0.4, the ‘sendemail’ REST API endpoint lets any authenticated user send an email as the Splunk instance. The endpoint is now restricted to the ‘splunk-system-user’ account on the local instance.

In Splunk Enterprise versions below 8.1.13, 8.2.10, and 9.0.4, the lookup table upload feature let a user upload lookup tables with unnecessary filename extensions. Lookup table file extensions may now be one of the following only: .csv, .csv.gz, .kmz, .kml, .mmdb, or .mmdb.gzl.

In Splunk Enterprise versions below 8.1.13, 8.2.10, and 9.0.4, the ‘search_listener’ parameter in a search allows for a blind server-side request forgery (SSRF) by an authenticated user. The initiator of the request cannot see the response without the presence of an additional vulnerability within the environment.

In Splunk Enterprise versions below 8.1.13, 8.2.10, and 9.0.4, the ‘display.page.search.patterns.sensitivity’ search parameter lets a search bypass SPL safeguards for risky commands. The vulnerability requires a higher privileged user to initiate a request within their browser and only affects instances with Splunk Web enabled.

In Splunk Enterprise versions below 8.1.13, 8.2.10, and 9.0.4, the ‘pivot’ search processing language (SPL) command lets a search bypass SPL safeguards for risky commands using a saved search job. The vulnerability requires an authenticated user to craft the saved job and a higher privileged user to initiate a request within their browser.

In Splunk Enterprise versions below 8.1.13, 8.2.10, and 9.0.4, a View allows for Cross-Site Scripting (XSS) in an extensible mark-up language (XML) View through the ‘layoutPanel’ attribute in the ‘module’ tag’.

In Splunk Enterprise 9.0 versions before 9.0.4, a View allows for Cross-Site Scripting (XSS) through the error message in a Base64-encoded image. The vulnerability affects instances with Splunk Web enabled. It does not affect Splunk Enterprise versions below 9.0.