CVE-2026-76364 in SOAR
Summary
by MITRE • 08/20/2026
In Splunk SOAR versions below 8.6.0, a user who holds the "Automation Engineer" Splunk SOAR role could run arbitrary Structured Query Language (SQL) statements against the Splunk SOAR database through custom function results, allowing for reading all relevant data stored in the Splunk SOAR database and affecting system integrity. The SQL injection is possible because Splunk SOAR builds the database lookup with the supplied name instead of a bound SQL value. For more information see Manage roles and permissions in Splunk SOAR (Cloud) (https://help.splunk.com/en/splunk-soar/soar-cloud/administer-soar-cloud/manage-your-splunk-soar-cloud-users-and-accounts/manage-roles-and-permissions-in-splunk-soar-cloud) in the Splunk documentation.
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 08/20/2026
A critical SQL injection vulnerability exists within Splunk SOAR versions prior to 8.6.0, specifically affecting users assigned the Automation Engineer role. This flaw allows an authenticated attacker with this specific privilege level to execute arbitrary Structured Query Language statements directly against the underlying database of the Splunk SOAR platform. The root cause lies in how the application constructs database lookup queries when processing custom function results. Instead of utilizing parameterized queries or bound SQL values, which would safely escape user-supplied input, the system concatenates the supplied name directly into the query string. This lack of proper input validation and sanitization creates a classic injection vector where maliciously crafted inputs can alter the intended logic of the database command.
The operational impact of this vulnerability is severe due to the high level of access granted by the Automation Engineer role, which is typically assigned to users responsible for developing and managing automated playbooks and integrations. By exploiting this flaw, an attacker can read sensitive data stored within the Splunk SOAR database, including potentially confidential security event logs, user credentials, integration secrets, and organizational intelligence gathered through security orchestration activities. Beyond confidentiality breaches, the ability to execute arbitrary SQL commands also threatens system integrity. An adversary could modify or delete critical records, disrupt ongoing automation workflows, or potentially escalate privileges further depending on the permissions of the database account used by the application. This undermines the trustworthiness of the Security Orchestration, Automation, and Response platform as a central hub for incident response operations.
From a classification perspective, this vulnerability aligns with CWE-89, which describes Improper Neutralization of Special Elements used in an SQL Command, commonly known as SQL Injection. The attack vector leverages the application's handling of user-controlled input within database queries without adequate encoding or escaping mechanisms. In terms of tactical mapping to the MITRE ATT&CK framework, this exploitation technique falls under T1059, specifically command and script interpretation variants that allow for data exfiltration via SQL commands (T1048). The vulnerability highlights a significant gap in input validation practices within custom function result handling modules.
To mitigate this risk, organizations running Splunk SOAR versions below 8.6.0 must upgrade to version 8.6.0 or later immediately upon availability from the vendor. This update addresses the underlying code flaw by implementing proper parameterization for database lookups involving custom function results. Until an upgrade is performed, administrators should strictly audit and restrict the Automation Engineer role assignment to only those individuals who absolutely require it for their operational duties. Implementing strict network segmentation and monitoring for anomalous SQL query patterns in the backend logs can also provide additional layers of defense against exploitation attempts by detecting unusual database activity originating from application endpoints.