Splunk SOAR vulnerabilities

In Splunk SOAR versions below 8.7.0, an unauthenticated user with access to encrypted credential data can submit Basic authentication data to the REST API to expose and decrypt that data. The vulnerability exists because Splunk SOAR decrypts encrypted Basic authentication values before completing authentication checks. The attack requires the user to possess encrypted credential data from an affected instance.

In Splunk SOAR versions below 8.7.0, an authenticated user could change the Enterprise Security edition through the REST API, causing Splunk SOAR to apply the license change. The vulnerability exists because Splunk SOAR authenticates requests to manage the Enterprise Security edition but does not authorize the caller before applying the license change.

In Splunk SOAR versions below 8.7.0, a user holding a role with the Users and Roles view permission could use the REST API to infer authentication token values for other users. If the inferred token grants administrative access, that user could gain administrative access to the Splunk SOAR instance. The vulnerability is possible because the REST API accepts caller-controlled query filters on sensitive user record fields.

In Splunk SOAR versions below 8.7.0, a user with the "Observer" role could use REST API query filters to infer password hashes and authorization tokens for other users. The disclosure occurs because query filters are applied to user records before sensitive fields are protected.

In Splunk SOAR versions below 8.7.0, an authenticated user who does not hold a role with permission to view apps could download an archive of an installed app. This could expose all data in the app archive, including proprietary source code and sensitive information. The vulnerability is possible because Splunk SOAR does not verify permission to view apps before it returns the app archive.

In Splunk SOAR versions below 8.7.0, an authenticated user who does not hold a role with permission to edit Automation Brokers could download the Splunk SOAR Automation Broker Docker Compose configuration file. The file contains the URL of the Splunk SOAR instance, the container image location, and the Splunk SOAR Automation Broker version. The vulnerability is possible because Splunk SOAR returns the configuration file without enforcing the Automation Broker edit permission.

In Splunk SOAR versions below 8.7.0, a user with a role holding the install_apps capability can install an app containing attacker-controlled content in its documentation, which Splunk SOAR does not sanitize before display. When another user with permission to view apps opens the app documentation, that content is executed in their browser, potentially allowing the attacker to access data and make changes with the victim's privileges.

In Splunk SOAR versions below 8.6.0, an authenticated user with restricted tenant access could use the REST API to view the names and identifiers of tenants outside their role scope. The vulnerability occurs because Splunk SOAR does not enforce role-based tenant restrictions when returning tenant information through the REST API in multi-tenancy deployments.

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.

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.

In Splunk SOAR versions below 8.6.0, a user with the "Incident Commander" role could store JavaScript in a note and run it in another user's browser when that user opens the note. The stored XSS vulnerability is possible because Splunk SOAR can treat existing note content as HTML without sanitizing it when the note format changes.

In Splunk SOAR versions below 8.6.0, a user with a valid Splunk SOAR account could use 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.

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 unauthenticated user who can observe or alter network traffic between Splunk SOAR and a configured CyberArk REST server could access or modify all relevant data exchanged through that credential manager. The vulnerability exists because the CyberArk REST client does not verify server certificates by default. The attack requires network-path interception capability between Splunk SOAR and the CyberArk REST server.

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.

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 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 SOAR versions below 8.5.0, an unauthenticated attacker could inject ANSI escape codes into SOAR application log files through specially crafted HTTP request paths. The injection is possible because SOAR does not strip control characters from HTTP request paths before writing them to application logs.

Splunk SOAR versions lower than 6.1.0 are indirectly affected by a potential vulnerability accessed through the user’s terminal. A third party can send Splunk SOAR a maliciously crafted web request containing special ANSI characters to cause log file poisoning.