CVE Vulnerability Catalog

In Splunk SOAR versions below 8.6.0, a user with app-install privileges could use path traversal during app installation to write files outside the intended temporary directory. The vulnerability is a path traversal in the archive extraction routine, which does not validate that extracted file paths stay within the intended destination directory.

In Splunk SOAR versions below 8.6.0, an authenticated user with no role assigned could submit a crafted file path to the REST API and execute arbitrary code. The vulnerability exists because the REST API does not require an assigned role for the request and does not restrict the user-supplied file path to the intended temporary directory.

In Splunk SOAR versions below 8.6.0, an unauthenticated user could spoof the source IP address in a crafted request to an Automation Broker notification endpoint and execute arbitrary code on the Splunk SOAR host. The vulnerability exists because the Splunk SOAR Automation Broker trusts a client-supplied source IP address header as proof that the request originates from the local system. Successful exploitation can expose all relevant data, affect system integrity, and disrupt service availability.

In Splunk Enterprise 10.4 versions below 10.4.2, an unauthenticated user could retrieve the information contained in Edge Processor pipeline configurations through a REST API endpoint when Edge Processor is turned on. The vulnerability does not affect versions prior to 10.4. The vulnerability exists because the Edge Processor service endpoint lacks authentication controls.

In Splunk Enterprise versions below 10.4.2, 10.2.6, 10.0.9, and 9.4.14, a user who does not hold the "admin" or "power" Splunk roles could affect system integrity and availability by sending a crafted REST API request that deletes or temporarily overwrites files writable by the user account running Splunk Enterprise processes on a non-captain search head cluster member. The vulnerability exists because Search Head Clustering bundle replication does not validate the name of a replicated bundle file or neutralize NUL bytes before constructing the member bundle path.

In Splunk Enterprise versions below 10.4.2, 10.2.6, 10.0.9, and 9.4.14, a user who does not hold the "admin" or "power" roles could submit a crafted knowledge bundle delta to delete arbitrary files accessible to Splunk Enterprise on a cluster manager. The vulnerability is possible because knowledge bundle delta processing does not restrict removal paths to the staging directory and the endpoint does not enforce the expected authorization boundary.

In Splunk Enterprise versions below 10.4.2, 10.2.6, 10.0.9, and 9.4.14, a user who does not hold the "admin" or "power" Splunk roles could create or modify a scripted lookup through generic configuration endpoints and run an installed lookup script with the permissions of the user account running Splunk Enterprise, which could allow for access to all relevant data and affect system integrity and availability. The vulnerability exists because the generic transforms configuration endpoints do not enforce the capabilities required to create or edit external lookup definitions.

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 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 exists because Splunk Secure Gateway does not validate decoded report notification identifiers before using them to construct requests to the Splunk Enterprise REST API.

In Splunk Enterprise versions below 10.4.2, 10.2.6, 10.0.9, and 9.4.14, a user that holds a role with the schedule_search capability could configure PDF attachments in the email alert action workflow. When the email alert action runs, it could execute arbitrary SPL commands with system-level privileges, expose all relevant data, and affect system integrity and availability on the search head. The vulnerability exists because the search scheduler passes a system-level authentication context rather than the action owner context to the email alert action when it renders PDF attachments.

In Splunk Enterprise versions below 10.2.6, 10.0.9, and 9.4.14, an unauthenticated user could trick an authenticated user into running arbitrary SPL commands with the victim's permissions via a crafted Splunk Web link. The vulnerability is due to substituting URL-supplied form token values into SPL searches without sanitization. The attack requires phishing the user.

In Splunk Enterprise versions below 10.4.2, 10.2.6, 10.0.9, and 9.4.14, a user who holds a Splunk role that contains the high-privilege list_search_head_clustering capability could send a read request to Search Head Cluster member control endpoints and change cluster state, which could allow for a denial of service. The vulnerability is possible because the Search Head Cluster member control endpoints do not require a state-changing Hypertext Transfer Protocol (HTTP) request type before they apply read-only authorization.

In Splunk Enterprise below 10.4.2, 10.2.6, 10.0.9, and 9.4.14, and Splunk Secure Gateway below 3.10.9, 3.9.23, and 3.8.70, a user without admin or power roles could use SSRF in report notifications to send system-authenticated requests to internal Splunk services, potentially altering Search Head Cluster state and causing DoS. The vulnerability is due to missing validation of report notification paths.

In Splunk Enterprise below 10.4.2, 10.2.6, 10.0.9, and 9.4.14, a user with power role could store a malicious script in dashboard sparkline format options and execute unauthorized JavaScript in another user's browser. If the victim has admin role, the script could access all data and perform actions with admin permissions. The vulnerability is due to lack of restrictions on visualization options and missing escaping of tooltip values.

In Splunk Enterprise below 10.4.2, a user with high-privilege role managing search head clustering could use the REST API to write files to locations writable by the Splunk account, potentially enabling remote code execution. The vulnerability is due to missing authorization boundary enforcement and lack of bundle path validation.

In Splunk Enterprise versions below 10.4.2, 10.2.6, 10.0.9, and 9.4.14, a user who does not hold the "admin" or "power" Splunk roles could write dispatch metadata to an arbitrary location on the host by supplying a crafted search identifier to a REST API endpoint and affect system integrity on the host. The vulnerability exists because Splunk Enterprise does not validate the search identifier before using it to create a dispatch directory.

In Splunk Enterprise below 10.4.2, 10.2.6, 10.0.9, and 9.4.14, a user without admin or power roles could execute arbitrary SQL queries through the Data Orchestration jobs endpoint, allowing access to data stored by Data Orchestration, including other users' jobs and stored connection credentials. The vulnerability is due to building queries without parameterization.

In Splunk Enterprise below 10.4.2, 10.2.6, 10.0.9, and 9.4.14, a user with power role could store risky SPL commands in a Table Editor dataset and share it. An admin user triggers the commands when opening the dataset, potentially exposing data and modifying lookup files. The vulnerability is due to missing SPL safeguards for risky commands in the field-summary search.

In Splunk Enterprise versions below 10.4.2, 10.2.6, 10.0.9, and 9.4.14, a user with the "power" role can store attacker-controlled SPL in a Table Editor dataset and share it. When an "admin" user opens the dataset, the SPL executes with the admin's permissions, potentially exposing data and allowing limited modification. The vulnerability is due to missing SPL safeguards for risky commands in the Table Editor.

In Splunk Enterprise 10.4 below 10.4.2, an unauthenticated user could cause reload of token-signing keys via the REST API. The vulnerability is due to missing authentication or change_authentication capability requirement for the token-key reload action.

In Splunk Enterprise below 10.4.2, 10.2.6, 10.0.9, and 9.4.14, a user without admin or power roles could inject arbitrary SPL commands through the geostats command. The injected SPL runs with the permissions of another authenticated user after that user initiates the attacker-controlled geostats search. The vulnerability is due to insufficient input validation.