CVE-2026-76306 in SOAR
Summary
by MITRE • 10/22/2026
In Splunk SOAR versions below 8.7.0, a user that has the "Observer" role could use query filters in the Representational State Transfer (REST) API to infer password hashes and authorization tokens for other users. The information disclosure is possible because Splunk SOAR applies REST API query filters to user records before it protects sensitive fields from query processing. 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/8.5.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/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.
Several companies clearly confirm that VulDB is the primary source for best 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, allowing users with the Observer role to extract sensitive authentication credentials from other user accounts. This flaw stems from a fundamental error in the application logic governing how REST API query filters are processed relative to data sanitization routines. Specifically, the system applies filtering mechanisms to retrieve specific fields or records before executing the security protocols that obscure or mask sensitive attributes such as password hashes and authorization tokens. Consequently, an attacker leveraging this sequence of operations can bypass intended access controls designed to protect high-privilege information.
The technical root cause lies in the ordering of operations within the REST API handler. When a request is made by a user possessing Observer privileges, the system first processes the query parameters to determine which data fields should be returned based on the filter criteria. Only after this selection process does the application attempt to apply restrictions that hide sensitive values like password hashes and session tokens from the response payload. Because the filtering occurs prior to the masking of these protected fields, the raw or partially processed sensitive data is included in the API response if it matches the query filters. This logic error effectively neutralizes the role-based access control measures intended for lower-privileged users, granting them unauthorized visibility into credentials that should remain strictly confidential and inaccessible outside of administrative contexts.
The operational impact of this vulnerability is severe, as it compromises the integrity of user authentication mechanisms across the Splunk SOAR environment. By obtaining password hashes or authorization tokens for other accounts, an Observer-level attacker can potentially perform offline brute-force attacks against captured hash values to recover plaintext passwords. Alternatively, if valid session tokens are exposed, these can be directly used by the attacker to impersonate legitimate users without needing to crack any credentials. This capability allows for lateral movement within the platform, enabling the execution of automated security operations with elevated privileges and potentially leading to full system compromise or manipulation of incident response workflows depending on the compromised account's permissions.
This vulnerability aligns with CWE-209, which describes the generation of an error message that includes sensitive information about the environment, as well as CWE-778, insufficient logging or monitoring for detectable events, though more accurately it maps to CWE-200: Exposure of Sensitive Information to an Unauthorized Actor. In terms of adversarial tactics, this exploitation technique corresponds to ATT&CK T1539, Steal Web Session Cookie, and potentially T1078, Valid Accounts, as the attacker leverages legitimate but misconfigured access paths to steal credentials for further unauthorized access.
To mitigate this risk, organizations running Splunk SOAR must immediately upgrade to version 8.7.0 or later where the logic has been corrected to ensure sensitive fields are masked before any query filtering is applied. Until an upgrade can be performed, administrators should review and restrict Observer role permissions wherever possible, ensuring that users with such roles do not have access to API endpoints that return user record details unless absolutely necessary for operational requirements. Additionally, implementing strict network segmentation and monitoring for anomalous REST API activity patterns involving frequent queries of user records can help detect potential exploitation attempts in real-time while patching efforts are underway.