CVE Vulnerability Catalog

In versions below 2.4.5 of the Cisco Secure Malware Analytics app for Splunk SOAR, a user with permission to run actions could expose a sensitive sample password by invoking the detonate file action, because the sample_password parameter is not masked and is shown in cleartext in the UI. This is possible because the app does not mark the parameter as a password.

In versions below 2.5.3 of the Azure AD Graph app for Splunk SOAR, a user with permission to run actions could expose a sensitive password by invoking the reset password action, because the temp_password parameter is not masked and is shown in cleartext in the UI. This is possible because the app does not mark the parameter as a password.

In versions below 2.1.9 of the AWS IAM app for Splunk SOAR, a user with permission to run actions could expose sensitive AWS credentials by invoking an action that accepts the credentials parameter, because the parameter is not masked and is shown in cleartext in the UI. This is possible because the app does not mark the parameter as a password.

In versions below 2.3.8 of the AD LDAP app for Splunk SOAR, a user with permission to run actions could expose sensitive credentials by invoking an action that causes the full connector process environment to be written to a persistent debug log file in plaintext.

In versions below 2.3.8 of the AD LDAP app for Splunk SOAR, a user with permission to run actions could cause sensitive Active Directory response data to be written to a persistent debug log file by triggering write operations through the app.

In versions below 2.3.8 of the AD LDAP app for Splunk SOAR, a user with permission to run actions could inject crafted input into an Active Directory query to enumerate Active Directory objects, including accounts, groups, and organizational units, read sensitive attributes from arbitrary directory objects, and redirect account modification actions to unintended objects.

In Nmap Scanner versions below 3.0.15, a user with a role that can edit, create, or run playbooks in Splunk SOAR could run the scan network action in a Safe Mode playbook while that action is listed as read-only, which could allow for command execution or other changes on a target system through Nmap Scripting Engine scripts. The vulnerability is possible because the action manifest classifies the action as read-only even though it accepts script parameters that can perform write operations.

In FireAMP versions below 2.1.15, a user with a role that can edit, create, or run playbooks in Splunk SOAR could run the add listitem action in a Safe Mode playbook while that action is listed as read-only, which could allow for unauthorized changes to file lists. The vulnerability is possible because the FireAMP connector action manifest classifies the add listitem action as read-only even though the action updates file lists.

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.