Threat Intelligence Database

In Splunk SOAR versions below 8.6.0, users with the OnPrem Broker role can write files outside the intended Automation Broker log directory due to insufficient validation of filenames during log uploads. This vulnerability allows limited unauthorized file write capabilities but does not impact confidentiality or availability. The issue is identified as CWE-22 (Path Traversal).

Splunk SOAR versions below 8.6.0 contain a vulnerability where an authenticated user with restricted tenant access can use the REST API to view tenant names and identifiers outside their role scope. This occurs because role-based tenant restrictions are not enforced properly in multi-tenant deployments when returning tenant information via the REST API.

Splunk SOAR versions below 8.6.0 contain a stored Cross-Site Scripting (XSS) vulnerability that allows a user with the "Incident Commander" role to store JavaScript in a note. This script can execute in the browser of another user when they open the note. The vulnerability arises because note content is treated as HTML without proper sanitization when the note format changes. Exploitation requires tricking the victim into initiating a request in their browser. The vulnerability has a moderate severity score and no known exploits in the wild.

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

An issue was discovered in Logpoint before 7.5.0. SOAR uses a static JWT secret key to generate tokens that allow access to SOAR API endpoints without authentication. This static key vulnerability enables attackers to create custom JWT secret keys for unauthorized access to these endpoints.

MediumVulnerabilityUnited StatesGermanyUnited Kingdom+7#cve#cve-2024-48952