CVE-2026-76361 in SOAR
Summary
by MITRE • 08/20/2026
In Splunk SOAR versions below 8.6.0, a user with the "Administrator" role could use the /rest/support/connectivity/.../check_connectivity endpoint to make Splunk SOAR initiate outbound network connections to arbitrary destinations and determine whether internal hosts and ports are reachable. The Server-Side Request Forgery (SSRF) is possible because the connectivity check REST API does not sufficiently validate the destination before Splunk SOAR connects to it. 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) in the Splunk documentation.
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 08/20/2026
The vulnerability identified in Splunk SOAR versions prior to 8.6.0 represents a critical Server-Side Request Forgery (SSRF) flaw within the platform's REST API infrastructure. This security defect specifically affects users holding the Administrator role, who possess elevated privileges that allow them to interact with internal management endpoints without sufficient scrutiny of their inputs. The core technical failure lies in the /rest/support/connectivity/.../check_connectivity endpoint, which is designed to perform network reachability checks but lacks robust validation mechanisms for the destination address provided by the caller. When an administrator submits a request through this API, the Splunk SOAR application initiates outbound connections to the specified target without verifying whether the destination is internal, external, or maliciously crafted. This absence of input sanitization and access control enforcement enables an authenticated attacker with administrative privileges to manipulate the server into making requests to arbitrary network locations.
From a technical perspective, this SSRF vulnerability allows for significant reconnaissance and potential exploitation within the underlying infrastructure hosting Splunk SOAR. By directing the application to connect to internal services that are not exposed to the public internet, such as metadata endpoints of cloud providers like AWS or Azure at 169.254.169.254, an attacker can extract sensitive configuration data, authentication tokens, and other credentials stored in instance metadata. Furthermore, because the endpoint determines whether hosts and ports are reachable, it serves as a powerful network scanning tool against internal networks. An adversary could systematically probe internal subnets to map out the network topology, identify active services, and discover vulnerable applications or databases that reside behind firewalls but are accessible from the Splunk SOAR host. This capability effectively bypasses perimeter security controls by leveraging the trusted position of the application server itself.
The operational impact of this vulnerability is severe due to the high privilege level required for exploitation. While it requires an Administrator account, such accounts often have access to sensitive orchestration playbooks and integration configurations that could be further compromised if internal credentials are exfiltrated via SSRF. The ability to scan internal networks can lead to lateral movement within the organization's environment, potentially escalating from a single application compromise to a full infrastructure breach. Additionally, this vulnerability undermines the principle of least privilege by allowing administrative functions intended for support and diagnostics to be repurposed as offensive tools against the host network. It also poses risks related to data exfiltration if internal services respond with sensitive information that can be captured through side-channel techniques or error messages returned by the API.
To mitigate this risk, organizations running Splunk SOAR versions below 8.6.0 must immediately apply the vendor-provided patch that addresses this SSRF flaw. The fix involves implementing stricter validation logic within the connectivity check endpoint to ensure that only authorized and safe destinations are permitted for outbound connections. In environments where immediate patching is not feasible, administrators should consider restricting access to the /rest/support/connectivity/ endpoints through network-level controls or by revoking specific API permissions from user roles if those capabilities are not strictly required for daily operations. Regular auditing of administrative account usage and monitoring for unusual outbound connection patterns can also help detect potential exploitation attempts. Adhering to industry standards such as CWE-918, which classifies Server-Side Request Forgery, highlights the importance of validating server-side inputs against a whitelist of allowed destinations rather than relying on blacklist approaches that may be bypassed through encoding or protocol variations.