CVE-2026-76304 in SOAR
Summary
by MITRE • 10/22/2026
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 Uniform Resource Locator (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. For more information see Install Splunk Automation Broker on a Docker host (https://help.splunk.com/en/splunk-soar/splunk-automation-broker/install-and-create-classic-splunk-soar-automation-brokers/install-splunk-automation-broker-on-a-docker-host) and 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.
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 10/22/2026
In versions of Splunk SOAR prior to 8.7.0, a critical access control flaw exists within the platform's handling of Automation Broker configuration files. This vulnerability allows any authenticated user who lacks the specific role permission required to edit or manage Automation Brokers to retrieve sensitive infrastructure details. The core technical issue stems from an improper implementation of authorization checks on the endpoint responsible for serving the Docker Compose configuration file associated with Splunk SOAR Automation Brokers. While the system correctly enforces permissions for actions that modify broker settings, it fails to validate whether the requesting user has sufficient privileges before returning the static configuration data. This discrepancy in access control logic creates a security gap where information intended for administrators or authorized operators is exposed to lower-privilege accounts within the same tenant environment.
The operational impact of this vulnerability centers on the exposure of sensitive infrastructure metadata contained within the Docker Compose file. When accessed, this file reveals the Uniform Resource Locator (URL) of the underlying Splunk SOAR instance, which can aid attackers in mapping the internal network topology and identifying primary attack surfaces. Furthermore, it discloses the specific container image location used for the Automation Broker service, providing insight into the software supply chain and potential dependencies that might be targeted. The disclosure also includes the exact version number of the Splunk SOAR Automation Broker currently deployed. This information is particularly dangerous as it allows threat actors to correlate the exposed version with known public vulnerabilities or exploit kits specific to that release, significantly lowering the barrier for subsequent exploitation attempts against the orchestration layer.
From a classification perspective, this vulnerability aligns directly with CWE-284, which describes Improper Access Control, specifically reflecting a failure in enforcing authorization policies on sensitive resources. It also maps to MITRE ATT&CK technique T1087, Account Discovery, as it enables an attacker to enumerate system configuration details that facilitate further reconnaissance and lateral movement within the Splunk SOAR environment. The flaw represents a classic case of broken object level permissions where the resource itself is not properly secured against unauthorized retrieval, even if the actions performed on related objects are correctly restricted.
To mitigate this risk, organizations running affected versions must upgrade to Splunk SOAR version 8.7.0 or later, which implements the necessary access control checks to prevent unprivileged users from downloading these configuration files. Until an upgrade is feasible, administrators should review their role and permission configurations in Splunk SOAR On-Premises to ensure that no unnecessary privileges are granted to low-level accounts. It is also advisable to monitor logs for unusual requests targeting Automation Broker endpoints and restrict network access to sensitive management interfaces where possible. Regular auditing of user roles against the principle of least privilege remains essential to minimize the impact of such authorization bypass vulnerabilities in enterprise security operations platforms.