CVE-2026-76305

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