CVE-2026-76307 in SOAR
Summary
by MITRE • 10/22/2026
In Splunk SOAR versions below 8.7.0, a user that holds a role with the Users and Roles view permission could use the Representational State Transfer (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. For more information see Using the REST API reference for Splunk SOAR (On-premises) (https://help.splunk.com/en/splunk-soar/soar-on-premises/rest-api-reference/7.1.0/using-the-splunk-soar-rest-api/using-the-rest-api-reference-for-splunk-soar-on-premises), Query for Data (https://help.splunk.com/en/splunk-soar/soar-on-premises/rest-api-reference/7.1.0/using-the-splunk-soar-rest-api/query-for-data), and Manage roles and permissions in Splunk SOAR (On-premises) (https://help.splunk.com/en/splunk-soar/soar-on-premises/administer-soar-on-premises/6.4.0/manage-your-splunk-soar-on-premises-users-and-accounts/manage-roles-and-permissions-in-splunk-soar-on-premises) in the Splunk documentation.
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 10/22/2026
A critical information disclosure vulnerability exists within Splunk SOAR versions prior to 8.7.0, specifically affecting instances where users are assigned roles possessing the Users and Roles view permission. This flaw allows an authenticated attacker with relatively low privileges to exploit improper input validation in the application's Representational State Transfer API interface. The core technical deficiency lies in the REST API endpoint responsible for querying user records, which accepts caller-controlled query filters on sensitive fields without adequate sanitization or restriction mechanisms. By leveraging these unrestricted filters, a malicious actor can construct specific requests that force the server to reveal authentication token values associated with other users within the system. This behavior constitutes an insecure direct object reference combined with improper limit control, as the application fails to restrict access to sensitive data based on the requester's actual privilege level relative to the target user records.
The operational impact of this vulnerability is severe due to its potential for lateral movement and privilege escalation. If a low-privileged user successfully infers or retrieves an authentication token belonging to a high-privilege account, they can utilize that token to authenticate as the administrative user. This effectively bypasses standard access controls and grants the attacker full administrative control over the Splunk SOAR instance. Such unauthorized access enables the execution of arbitrary actions, including modifying security policies, accessing sensitive investigation data, deploying malicious playbooks, or disrupting incident response operations. The ability to enumerate valid tokens undermines the integrity of the authentication mechanism and compromises the confidentiality of user credentials within the platform.
From a classification perspective, this vulnerability aligns with CWE-200: Exposure of Sensitive Information to an Unauthorized Actor and CWE-613: Insufficient Session Expiration. In terms of adversary tactics, it maps directly to ATT&CK technique T1528: Steal Application Access Token, which describes the method attackers use to steal application access tokens from cloud accounts or web applications for further exploitation. The attack vector is primarily remote and requires authentication, placing it within the initial access phase of a cyber kill chain but with significant potential for immediate privilege escalation upon success.
To mitigate this risk, organizations running Splunk SOAR versions below 8.7.0 must apply the vendor-provided patch immediately to update to version 8.7.0 or later. This release addresses the underlying logic error in the REST API query handling that permits unauthorized data inference. In addition to applying patches, administrators should review and restrict user roles to ensure that only necessary personnel have access to Users and Roles view permissions. Implementing strict role-based access control principles helps minimize the attack surface by limiting the number of users capable of interacting with sensitive endpoints. Furthermore, enabling comprehensive logging and monitoring for unusual API query patterns can aid in early detection of exploitation attempts targeting these specific REST endpoints.