| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| In Splunk Enterprise versions below 10.4.2, a user with a high-privilege Splunk role that can manage search head clustering could use the search head cluster member bundle Representational State Transfer (REST) API to write files to locations that the user account running Splunk Enterprise can write to, which could allow for remote code execution. Successful exploitation could result in access to all relevant data and could affect the integrity and availability of the Splunk deployment. The vulnerability does not affect Splunk Enterprise versions below 10.4. The vulnerability is possible because the search head cluster member bundle REST API does not enforce the expected authorization boundary and does not validate bundle paths before accepting bundle content. For more information see Using the REST API reference (https://help.splunk.com/en/splunk-enterprise/rest-api-reference/10.2/introduction/using-the-rest-api-reference), About configuring role-based user access (https://help.splunk.com/en/splunk-enterprise/administer/manage-users-and-security/10.2/manage-splunk-platform-users-and-roles/about-configuring-role-based-user-access), and About distributed search (https://help.splunk.com/en/splunk-enterprise/administer/distributed-search/9.4/overview-of-distributed-search/about-distributed-search) in the Splunk documentation. |
| In Splunk Enterprise versions below 10.4.2, 10.2.6, 10.0.9, and 9.4.14, a low-privileged user that does not hold the "admin" or "power" Splunk roles could inject Structured Query Language (SQL) through the Representational State Transfer (REST) API, causing Splunk Enterprise to evaluate attacker-controlled text as part of a database query. The SQL injection is possible because the REST API incorporates user-supplied filter values into database queries without proper neutralization. |
| In Splunk AI Toolkit versions below 6.0.0, a user who holds the "power" Splunk role could access and delete all relevant data in experiment history, including data associated with other users. The vulnerability is possible because Splunk AI Toolkit does not preserve the trusted experiment scope when it processes caller-controlled query values before accessing restricted history data. For more information see Experiment Assistants (https://help.splunk.com/en/splunk-cloud-platform/apply-machine-learning/use-ai-toolkit/5.6.4/experiment-assistants) in the Splunk documentation. |
| In Splunk AI Toolkit versions below 6.0.0, a user that holds a role with the schedule_search capability could cause a scheduled search to load and deserialize a model file through the apply search command. The improper access control is possible because Splunk AI Toolkit does not mark the apply search command as risky. For more information see Troubleshoot the AI Toolkit (https://help.splunk.com/en/splunk-enterprise/apply-machine-learning/use-ai-toolkit/5.7.3/troubleshooting-the-ai-toolkit/troubleshoot-the-ai-toolkit) in the Splunk documentation. |
| In Splunk AI Toolkit versions below 6.0.0, a user who holds the "power" Splunk role could execute arbitrary code on the Splunk server by loading a model file containing crafted sparse matrix data. The deserialization of untrusted data is possible because a model codec in Splunk AI Toolkit deserializes sparse matrix data without guarding against embedded pickle content. For more information see Troubleshoot the Splunk Machine Learning Toolkit (https://help.splunk.com/en/splunk-cloud-platform/apply-machine-learning/machine-learning-toolkit-user-guide/5.5.0/troubleshooting-mltk/troubleshoot-the-splunk-machine-learning-toolkit) in the Splunk documentation. |
| In Splunk AI Toolkit versions below 6.0.0, a low-privileged user who does not hold the "admin" or "power" Splunk roles could start, stop, and configure containers, and read or modify connection and configuration data through the Representational State Transfer (REST) API. The missing authorization is possible because multiple REST API handlers in Splunk AI Toolkit do not enforce authorization checks. For more information see Troubleshoot the Splunk Machine Learning Toolkit (https://help.splunk.com/en/splunk-cloud-platform/apply-machine-learning/machine-learning-toolkit-user-guide/5.5.0/troubleshooting-mltk/troubleshoot-the-splunk-machine-learning-toolkit) in the Splunk documentation. |
| In Splunk AI Toolkit versions below 6.0.0, a user who can upload models could overwrite a model being uploaded by another user by sending a concurrent upload request for the same model name, causing the resulting model lookup entry to reference attacker-controlled content. The race condition is possible because Splunk AI Toolkit does not verify that the uploaded content belongs to the request that creates the model lookup entry. For more information see Troubleshoot the Splunk Machine Learning Toolkit (https://help.splunk.com/en/splunk-cloud-platform/apply-machine-learning/machine-learning-toolkit-user-guide/5.5.0/troubleshooting-mltk/troubleshoot-the-splunk-machine-learning-toolkit) in the Splunk documentation. |
| In Splunk AI Toolkit versions below 6.0.0, a user who does not hold the "admin" or "power" Splunk roles could obtain predictable or default credentials for connected container services. The use of hard-coded credentials is possible because Splunk AI Toolkit generates or stores credentials for connected container services using predictable or hard-coded default values. For more information see Connections tab in the AI Toolkit (https://help.splunk.com/en/splunk-cloud-platform/apply-machine-learning/use-ai-toolkit/5.7.2/ai-toolkit-commands-macros-and-visualizations/connections-tab-in-the-ai-toolkit) in the Splunk documentation. |
| In Splunk AI Toolkit versions below 6.0.0, a user who does not hold the "admin" or "power" Splunk roles could run searches with system-level privileges, access all relevant data, affect system integrity, and read or delete search jobs belonging to other users through Agent Run History. The improper privilege management is possible because the Agent Run History handler replaces the calling user session key with a system authentication token before it performs search operations. For more information see AI Toolkit Agent Launchpad (https://help.splunk.com/en/splunk-enterprise/apply-machine-learning/use-ai-toolkit/6.0.0/ai-toolkit-connections-containers-and-agents/ai-toolkit-agent-launchpad) in the Splunk documentation. |
| In Splunk SOAR versions below 8.6.0, an unauthenticated user who can observe or alter network traffic between Splunk SOAR and a configured CyberArk Representational State Transfer (REST) server could access or modify all relevant data exchanged through that credential manager. The vulnerability is possible because the CyberArk REST client does not verify server certificates by default. The attack requires the attacker to have network-path interception capability between Splunk SOAR and the configured CyberArk REST server. For more information see Manage your organization's credentials with a password vault (https://help.splunk.com/en/splunk-soar/soar-cloud/administer-soar-cloud/configure-administration-settings-in-splunk-soar-cloud/manage-your-organizations-credentials-with-a-password-vault) in the Splunk documentation. |
| In Splunk SOAR versions below 8.6.0, a user with a valid Splunk SOAR account could use Representational State Transfer (REST) API filtering on playbook runs to recover session tokens that compromise all data available to the affected user. The information disclosure is possible because Splunk SOAR does not block REST API filters from matching values that responses otherwise hide. For more information see REST Run Playbook (https://help.splunk.com/en/splunk-soar/soar-cloud/rest-api-reference/run-playbook-endpoints/rest-run-playbook) in the Splunk documentation. |
| 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 is possible 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. For more information see About Splunk SOAR Automation Broker (https://help.splunk.com/en/splunk-soar/splunk-automation-broker/about-splunk-soar-automation-broker/about-splunk-soar-automation-broker) in the Splunk documentation. |
| In Splunk SOAR versions below 8.6.0, a user who holds the "Automation Engineer" Splunk SOAR role could run arbitrary Structured Query Language (SQL) statements against the Splunk SOAR database through custom list retrieval in a playbook, allowing for create, read, update, and delete operations on all relevant data stored in the Splunk SOAR database. 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. For more information see Manage roles and permissions in Splunk SOAR (https://help.splunk.com/en/splunk-soar/soar-cloud/administer-soar-cloud/manage-your-splunk-soar-cloud-users-and-accounts/manage-roles-and-permissions-in-splunk-soar-cloud) and Create custom lists for use in Splunk SOAR playbook comparisons (https://help.splunk.com/en/splunk-soar/soar-cloud/build-playbooks/manage-playbooks-and-playbook-settings/create-custom-lists-for-use-in-splunk-soar-cloud-playbook-comparisons) in the Splunk documentation. |
| In Splunk SOAR versions below 8.6.0, a user who holds the "Automation Engineer" role could run arbitrary Structured Query Language (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. For more information see Manage roles and permissions in Splunk SOAR Cloud (https://help.splunk.com/en/splunk-soar/soar-cloud/administer-soar-cloud/manage-your-splunk-soar-cloud-users-and-accounts/manage-roles-and-permissions-in-splunk-soar-cloud) in the Splunk documentation. |
| In Splunk SOAR versions below 8.6.0, a user who holds the "Automation Engineer" Splunk SOAR role could run arbitrary Structured Query Language (SQL) statements against the Splunk SOAR database through custom function results, allowing for reading all relevant data stored in the Splunk SOAR database 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. For more information see Manage roles and permissions in Splunk SOAR (Cloud) (https://help.splunk.com/en/splunk-soar/soar-cloud/administer-soar-cloud/manage-your-splunk-soar-cloud-users-and-accounts/manage-roles-and-permissions-in-splunk-soar-cloud) in the Splunk documentation. |
| In Splunk SOAR versions below 8.6.0, an authenticated user with restricted tenant access could use the Representational State Transfer (REST) API to view the names and identifiers of tenants that fall outside the role scope for that user. The vulnerability is possible because Splunk SOAR does not enforce role-based tenant restrictions when it returns tenant information through the REST API in deployments with multi-tenancy turned on. For more information see REST Roles and Permissions (https://help.splunk.com/en/splunk-soar/soar-cloud/rest-api-reference/role-management-endpoints/rest-roles-and-permissions) and Configure multiple tenants on your Splunk SOAR (On-premises) instance (https://help.splunk.com/en/splunk-soar/soar-on-premises/administer-soar-on-premises/7.1.0/configure-product-settings-for-your-splunk-soar-on-premises-instance/configure-multiple-tenants-on-your-splunk-soar-on-premises-instance) in the Splunk documentation. |
| In Splunk SOAR versions below 8.6.0, a user who holds the OnPrem Broker role could write files outside the intended Automation Broker log directory. The vulnerability is possible because Automation Broker log uploads accept crafted filename input before writing log files. For more information see Manage roles and permissions in Splunk SOAR (Cloud) (https://help.splunk.com/en/splunk-soar/soar-cloud/administer-soar-cloud/manage-your-splunk-soar-cloud-users-and-accounts/manage-roles-and-permissions-in-splunk-soar-cloud) and About Splunk SOAR Automation Broker (https://help.splunk.com/en/splunk-soar/splunk-automation-broker/about-splunk-soar-automation-broker/about-splunk-soar-automation-broker) in the Splunk documentation. |
| In Splunk SOAR versions below 8.6.0, a user who holds a role that contains the playbooks:view permission could view metadata about a playbook repository that they are not authorized to view. The vulnerability is possible because Playbook History does not check repository permissions before returning playbook revision metadata. For more information see Manage roles and permissions in Splunk SOAR (Cloud) (https://help.splunk.com/en/splunk-soar/soar-cloud/administer-soar-cloud/manage-your-splunk-soar-cloud-users-and-accounts/manage-roles-and-permissions-in-splunk-soar-cloud) and Manage settings for a playbook in Splunk SOAR (Cloud) (https://help.splunk.com/en/splunk-soar/soar-cloud/build-playbooks/manage-playbooks-and-playbook-settings/manage-settings-for-a-playbook-in-splunk-soar-cloud) in the Splunk documentation. |
| In Splunk SOAR versions below 8.6.0, a user with the "Administrator" role could use the /rest/support/connectivity/.../check_connectivity endpoint to make Splunk SOAR initiate outbound network connections to arbitrary destinations and determine whether internal hosts and ports are reachable. The Server-Side Request Forgery (SSRF) is possible because the connectivity check REST API does not sufficiently validate the destination before Splunk SOAR connects to it. For more information see Manage roles and permissions in Splunk SOAR (On-premises) (https://help.splunk.com/en/splunk-soar/soar-on-premises/administer-soar-on-premises/8.5.0/manage-your-splunk-soar-on-premises-users-and-accounts/manage-roles-and-permissions-in-splunk-soar-on-premises) in the Splunk documentation. |
| 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. For more information see Manage roles and permissions in Splunk SOAR (On-premises) (https://help.splunk.com/en/splunk-soar/soar-on-premises/administer-soar-on-premises/8.5.0/manage-your-splunk-soar-on-premises-users-and-accounts/manage-roles-and-permissions-in-splunk-soar-on-premises) and Monitor the health of your Splunk SOAR (On-premises) system (https://help.splunk.com/en/splunk-soar/soar-on-premises/administer-soar-on-premises/8.5.0/manage-your-splunk-soar-on-premises-system-health-and-performance/monitor-the-health-of-your-splunk-soar-on-premises-system) in the Splunk documentation. |
