This CVE exposes a fundamental design flaw in Splunk SOAR: the custom list retrieval feature — a core capability for Automation Engineers — passes user-supplied list names directly into SQL queries rather than using parameterized lookups. This was not an accidental gap; it is how the feature was architected from inception. An authorized Automation Engineer can inject arbitrary SQL statements and perform CRUD operations across the entire SOAR database through what should be a straightforward data retrieval function.
The CVSS score of 6.5 is misleading. It treats the authentication requirement as a meaningful security boundary, but if an entire role class is architecturally granted database-level access through a legitimate feature, that boundary is illusory. Compromising an Automation Engineer account — through phishing, credential stuffing, or supply chain attacks on their integrations — gives you a skeleton key to every system SOAR touches: ticketing platforms, SIEMs, incident response workflows, and the playbook logic governing your organization's breach response.
Upgrade to 8.6.0 or later immediately. However, scrutinize what the fix actually changed at the code level. If Splunk added input validation or denylisting rather than true parameterized queries, the injection class persists — just behind a different filter. Review your existing playbooks for other custom list lookups or similar SQL-based patterns that may carry the same structural risk. The remediation path should eliminate raw SQL construction entirely from this workflow; if parameterized API access exists after the patch, verify that all custom list operations now route through it. The attack surface does not disappear with a version bump — it shifts toward unpatched systems, incomplete fixes, and organizations that assume the CVE is behind them.