CVE-2026-76357 in SOAR
Summary
by MITRE • 08/20/2026
In Splunk SOAR versions below 8.6.0, an authenticated user with no role assigned could submit a crafted file path to the Representational State Transfer (REST) API and execute arbitrary code. The vulnerability is possible because the REST API does not require an assigned role for the request and does not restrict the user-supplied file path to the intended temporary directory. For more information see 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) and Splunk SOAR (On-premises) security information (https://help.splunk.com/en/splunk-soar/soar-on-premises/administer-soar-on-premises/8.5.0/introduction-to-splunk-soar-on-premises/splunk-soar-on-premises-security-information) 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 • 08/20/2026
The vulnerability identified in Splunk SOAR versions prior to 8.6.0 represents a critical security flaw rooted in improper access control and path traversal mechanisms within the application's Representational State Transfer API interface. This issue allows an authenticated user who has not been assigned any specific role or permissions to execute arbitrary code on the underlying system. The core of the problem lies in two distinct failures: first, the REST endpoint does not enforce a mandatory role requirement for incoming requests, and second, it fails to properly sanitize or restrict file paths provided by users, allowing them to reference locations outside the intended temporary directory structure. This combination creates an environment where low-privilege accounts can bypass standard authorization checks and manipulate system files in ways that were never intended by the application designers.
From a technical perspective, this vulnerability is classified under CWE-269 Improper Privilege Management because it allows users with insufficient privileges to perform actions requiring higher levels of authority or no authority at all. Additionally, the mechanism used to exploit the flaw aligns closely with CWE-22 Path Traversal: Incorrect Resolution of Parent or Multiple Relative Paths, as attackers can use crafted file paths to escape the sandboxed temporary directory and access sensitive system areas. In terms of offensive security frameworks, this behavior is consistent with ATT&CK technique T1059 Command and Scripting Interpreter, specifically through local command execution via API manipulation, which enables adversaries to gain a foothold within the infrastructure by leveraging legitimate administrative interfaces for malicious purposes.
The operational impact of this vulnerability is severe due to the nature of Splunk SOAR as a Security Orchestration, Automation, and Response platform that often handles sensitive security data and integrates with critical enterprise systems. An attacker who successfully exploits this flaw can achieve remote code execution on the server hosting the application. This level of access typically leads to full system compromise, allowing the adversary to exfiltrate confidential information, install additional malware such as backdoors or ransomware, pivot into other parts of the network, and disrupt security operations by altering logs or disabling monitoring capabilities. Since the vulnerability affects authenticated users with no role assigned, it is particularly dangerous in environments where default accounts or newly created user profiles may lack explicit permission sets but still possess valid login credentials.
To mitigate this risk, organizations running Splunk SOAR on-premises must immediately upgrade to version 8.6.0 or later, as these versions include the necessary patches to enforce role-based access control strictly and validate file paths against allowed directories. Until an upgrade is feasible, administrators should review user accounts to ensure that no users exist with valid credentials but zero assigned roles, effectively removing any potential attack vectors associated with unprivileged authenticated sessions. Furthermore, implementing network-level controls such as firewalls or web application firewalls can help restrict access to the REST API endpoints to only known and trusted IP addresses, adding a layer of defense in depth while the patching process is underway. Regular audits of user permissions and adherence to the principle of least privilege are essential practices to prevent similar vulnerabilities from being exploited in the future.