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, a user who holds the "Incident Commander" Splunk SOAR role could store JavaScript in a note and run it in the browser of another user when that user opens the note. The stored Cross-Site Scripting (XSS) vulnerability is possible because Splunk SOAR can treat existing note content as Hypertext Markup Language (HTML) without sanitizing that content when the note format changes. The vulnerability requires the attacker to phish the affected user by tricking them into initiating a request within their browser. The user who holds the "Incident Commander" Splunk SOAR role should not be able to exploit the vulnerability at will. 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 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 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, 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 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, 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, 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.