CVE Vulnerability Catalog

In Splunk SOAR versions below 8.6.0, a user with the "Automation Engineer" role could run arbitrary SQL statements against the Splunk SOAR database through custom list retrieval in a playbook, allowing create, read, update, and delete operations on all relevant data. The SQL injection is possible because Splunk SOAR builds the custom list database lookup with the supplied list name instead of a bound SQL value.

In Splunk SOAR versions below 8.6.0, a user with the "Automation Engineer" role could run arbitrary SQL statements against the Splunk SOAR database through custom function results, allowing reading all relevant data and affecting system integrity. The SQL injection is possible because Splunk SOAR builds the database lookup with the supplied name instead of a bound SQL value.

In Splunk SOAR versions below 8.6.0, a user with the "Automation Engineer" role could run arbitrary SQL statements against the Splunk SOAR database and create, read, update, or delete all data in the database. The vulnerability is possible because Splunk SOAR playbook automation data APIs incorporate user-supplied input into database queries without proper neutralization.

In Splunk SOAR versions below 8.6.0, an authenticated user with no role assigned could use the /rest/health endpoint to gather system and cluster telemetry that should be restricted to administrative or support users. The vulnerability is a missing authorization check, where the endpoint does not verify that the caller holds a role permitted to view system health and cluster state.

In Splunk SOAR versions below 8.6.0, a user with the Administrator role could use path traversal in the Universal Forwarder installer's archive extraction to write files outside the intended installation directory. The vulnerability is possible because the Universal Forwarder credentials-package extraction workflow does not verify that each archive member remains within the intended destination before extraction.

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 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.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 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 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.

In Splunk Enterprise below 10.4.2, 10.2.6, 10.0.9, and 9.4.14, an unauthenticated user could read JavaScript files outside the Splunk Web static directory. The vulnerability is due to lack of restriction of static file requests to the configured static directory.

A user with the "power" role in Splunk Enterprise can store a Dashboard Studio workflow action containing attacker-controlled SPL. When another authenticated user selects the action, Splunk runs the injected SPL with that user's permissions, potentially allowing access or modification of data. The vulnerability is due to insufficient validation of workflow-action URLs in Dashboard Studio.

An unauthenticated attacker can trick a user with the "admin" role into opening a crafted link to Monitoring Console. When opened, Splunk Enterprise runs attacker-controlled SPL with that user's permissions, potentially exposing data or modifying lookup data. The vulnerability is due to insufficient validation of data used to build dashboard searches in Monitoring Console.

A user with the "power" role can store attacker-controlled SPL in a dashboard. When another authenticated user exports the dashboard as a PDF, Splunk Enterprise runs the injected SPL with that user's permissions, potentially allowing access or modification of data. The vulnerability is due to insufficient validation of dashboard content before processing PDF exports.