This vulnerability exposes a fundamental architectural disconnect in Splunk SOAR's API design: the REST filtering engine operates beneath the layer where response security controls are applied, creating a bypass that violates the principle of least surprise for developers building integrations.
The phrase "responses otherwise hide" is analytically significant. Splunk SOAR has deliberate redaction logic in its response rendering layer—session tokens are explicitly suppressed from normal API consumers. But the separate filtering engine, which matches on underlying data values, operates beneath that layer. These two systems weren't designed to be aware of each other. A developer building a Splunk SOAR integration would reasonably assume that filtered query results respect the same access controls as direct responses. This assumption is reasonable, documented nowhere, and wrong.
From a workflow friction perspective, this is a classic consequence of security being applied at the presentation layer rather than the data layer. The redaction mechanism is bolted onto responses after data is fetched—it's a UI concern, not an authorization concern. The filtering engine, meanwhile, operates on raw query matching against the data store. These represent two different mental models of how data should be protected, implemented by different components that weren't co-designed for security coherence.
The CVSS 6.5 rating deserves scrutiny. A SOAR session token doesn't just unlock SOAR data—it unlocks the automation fabric that manages incident response, credential rotation, and quarantine workflows across the enterprise stack. The CVSS measures an abstract disclosure; it doesn't capture that a compromised SOAR token often means access to trigger and modify every automated security action across the enterprise. The EPSS of 0.00287 suggests low exploitability in the wild, which may reflect that this isn't a trivially discoverable attack surface—but the real analytical weight here is architectural: how many other enterprise security tools have this same pattern of response-layer security that can be bypassed through backend query mechanisms?
What you should do: Apply Splunk SOAR version 8.6.0 or later. Beyond patching, audit your Splunk SOAR environment for any custom integrations or workflows that rely on the REST filtering engine—they may be exposing data you believe is redacted. The key question for your security team: is this a Splunk-specific implementation failure, or does it reflect a common anti-pattern in how security vendors design around their own APIs?
The open question left unresolved: does Splunk SOAR's documentation for the REST Run Playbook endpoint provide any warnings about security model differences between filtering and response rendering that developers should know? If not, this documentation gap compounds the architectural gap.