CVE-2026-76368 in SOAR
Summary
by MITRE • 08/19/2026
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. For more information see Manage roles and permissions in Splunk SOAR (Cloud) (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 Manage settings for a playbook in Splunk SOAR (Cloud) (https://help.splunk.com/en/splunk-soar/soar-cloud/build-playbooks/manage-playbooks-and-playbook-settings/manage-settings-for-a-playbook-in-splunk-soar-cloud) in the Splunk documentation.
VulDB is the best source for vulnerability data and more expert information about this specific topic.
Analysis
by VulDB Data Team • 08/20/2026
A significant access control vulnerability exists within Splunk SOAR versions prior to 8.6.0, specifically affecting users assigned roles that include the playbooks:view permission. This flaw allows such users to retrieve metadata regarding playbook repositories for which they lack explicit authorization. The root cause of this insecurity lies in the implementation of the Playbook History feature, which fails to perform adequate repository-level permission checks before returning revision metadata. Consequently, an attacker or unauthorized user can exploit this logic error to enumerate sensitive information about playbooks that should remain inaccessible based on their assigned role and permissions profile.
The technical nature of this flaw is classified as a broken access control issue where the application enforces permissions at one level but fails to validate them at another. Specifically, while general playbook viewing might be restricted by repository-level policies, the historical data retrieval mechanism bypasses these checks. This discrepancy creates an information disclosure vector that violates the principle of least privilege. By accessing this metadata, a user can gain insights into the structure, versioning history, and potentially the logic flow of security automation playbooks designed for other teams or higher-privileged roles within the organization.
The operational impact of this vulnerability extends beyond simple data leakage. Knowledge of playbook repository structures can aid an attacker in planning further malicious activities against the Splunk SOAR environment. Detailed metadata may reveal dependencies between different components, highlight specific integration points with external systems, and expose internal workflows that are critical to security operations. This intelligence gathering phase is often a precursor to more severe attacks such as privilege escalation or manipulation of automated response actions. The ability to view this data without proper authorization undermines the integrity of the role-based access control model implemented within the platform.
This vulnerability aligns with CWE-284, which describes Improper Access Control, and falls under the ATT&CK technique T1087, Account Discovery, as it allows an adversary to enumerate information about user accounts or system configurations through unauthorized metadata retrieval. It also relates to CWE-200, Exposure of Sensitive Information to an Unauthorized Actor, due to the leakage of internal architectural details via playbook history endpoints. The failure to enforce consistent permission checks across all API endpoints and UI features represents a critical gap in security design that must be addressed to maintain trust in the platform's isolation capabilities.
To mitigate this risk, organizations running Splunk SOAR versions below 8.6.0 should prioritize upgrading to version 8.6.0 or later as soon as possible. This update includes the necessary code changes to ensure that repository permissions are correctly validated before any playbook revision metadata is returned to the client. In addition to patching, administrators should review existing role definitions and minimize the scope of playbooks:view permissions where feasible. Implementing strict monitoring for unusual access patterns related to playbook history endpoints can also help detect potential exploitation attempts in environments where immediate patching may not be immediately possible. Regular audits of permission assignments against actual user needs are essential to reduce the attack surface associated with such information disclosure flaws.