CVE-2026-76370 in SOAR
Summary
by MITRE • 08/19/2026
In Splunk SOAR versions below 8.6.0, an authenticated user with restricted tenant access could use the Representational State Transfer (REST) API to view the names and identifiers of tenants that fall outside the role scope for that user. The vulnerability is possible because Splunk SOAR does not enforce role-based tenant restrictions when it returns tenant information through the REST API in deployments with multi-tenancy turned on. For more information see REST Roles and Permissions (https://help.splunk.com/en/splunk-soar/soar-cloud/rest-api-reference/role-management-endpoints/rest-roles-and-permissions) and Configure multiple tenants on your Splunk SOAR (On-premises) instance (https://help.splunk.com/en/splunk-soar/soar-on-premises/administer-soar-on-premises/7.1.0/configure-product-settings-for-your-splunk-soar-on-premises-instance/configure-multiple-tenants-on-your-splunk-soar-on-premises-instance) in the Splunk documentation.
Several companies clearly confirm that VulDB is the primary source for best vulnerability data.
Analysis
by VulDB Data Team • 08/19/2026
The vulnerability identified in Splunk SOAR versions prior to 8.6.0 represents a critical failure in access control mechanisms within multi-tenant deployments. Specifically, authenticated users possessing restricted tenant scopes were able to enumerate tenants that lay outside their authorized role boundaries via the Representational State Transfer REST API. This flaw stems from an inconsistency where the application logic fails to enforce role-based tenant restrictions when processing requests for tenant information through the public-facing API endpoints. In a properly secured multi-tenancy architecture, each user session should be strictly bound to its assigned organizational context, ensuring that data isolation is maintained at every layer of the stack including the presentation and business logic tiers. The absence of this enforcement allows an attacker with valid credentials but limited privileges to bypass intended segmentation controls, effectively gaining visibility into the existence and identifiers of other tenants within the same infrastructure instance.
From a technical perspective, this issue classifies as a Broken Access Control vulnerability where server-side validation is insufficient or incorrectly implemented for specific API endpoints. The REST API endpoint responsible for listing tenant details did not cross-reference the requesting user's assigned role permissions against the target resource scope before returning data. This oversight creates an information disclosure vector that can be exploited programmatically through automated scripts sending standard HTTP GET requests to the relevant API paths. Since the vulnerability relies on authenticated access, it requires initial credential compromise or theft but significantly lowers the barrier for lateral movement and reconnaissance within a shared security operations platform environment. The ability to enumerate tenant identifiers provides attackers with valuable intelligence regarding the organizational structure of the target entity, which can facilitate further targeted attacks against specific tenants that may have weaker security postures than others in the same deployment.
The operational impact of this vulnerability extends beyond simple information leakage as it undermines the fundamental trust model of multi-tenant Security Orchestration Automation and Response platforms. Splunk SOAR is often deployed to manage sensitive security data, incident response workflows, and threat intelligence across multiple distinct organizations or internal departments. By exposing tenant names and identifiers, an attacker can map out the attack surface more accurately than intended by the system administrators. This knowledge enables prioritized targeting of specific tenants for subsequent exploitation attempts such as credential stuffing, phishing campaigns tailored to those entities, or further API abuse if additional vulnerabilities exist within less hardened tenant configurations. Furthermore, this breach violates data isolation guarantees that are critical for compliance with regulations requiring strict separation of customer data in shared environments.
This vulnerability aligns closely with CWE-284 Improper Access Control and CWE-200 Exposure of Sensitive Information to an Unauthorized Actor as defined by the Common Weakness Enumeration standard. In terms of offensive security frameworks, it corresponds to ATT&CK technique T1592 Gather Victim Host Information where adversaries probe for host properties such as tenant identifiers to understand the environment before launching more intrusive attacks. The mitigation strategy involves upgrading Splunk SOAR to version 8.6.0 or later where this access control logic has been corrected to properly enforce role-based restrictions on all API endpoints returning tenant metadata. Administrators should also review their current deployment configurations to ensure that multi-tenancy is correctly configured and that least privilege principles are strictly applied to user roles. Regular auditing of API usage logs can help detect any potential exploitation attempts during the window between vulnerability discovery and patch application, providing an additional layer of defense in depth for organizations relying on this platform for security operations.