Splunk SOAR CVE-2026-76531

Requires network reachability to a Splunk SOAR instance running a version below 8.7.0, plus a low-privileged authenticated account (CVSS PR:L); no user interaction is needed (UI:N) and attack complexity is low (AC:L). The specific product feature, API endpoint, or configuration that exposes the files/directories is not described in the available sources (generic CWE-552 bundled advisory), so the exact trigger is unverified. Limiting factors: exploitation is not possible by a fully unauthenticated attacker per the vector, SSVC marks it not automatable, and upgrading to Splunk SOAR 8.7.0 remediates it.

The vendor CVSS 3.1 vector (AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H, 9.9) describes a network-reachable, low-complexity flaw requiring only low-level authentication, with a scope change and total confidentiality/integrity/availability impact. The SSVC framework agrees on the severity of outcome (Technical Impact: total) but reports Exploitation: none and Automatable: no, meaning CISA's data shows no observed exploitation and no evidence it can be automated. There is no CISA KEV listing and no EPSS score in the supplied data, and no PoC or exploit reference is present, so exploitation status is: no public exploit identified at time of analysis. This creates a genuine tension: the vuln.today Decision label is act_now (driven largely by the 9.9 total-impact rating and the authenticated-but-network vector), yet the exploitation signals (SSVC none, no KEV, no PoC) point to a high-severity-but-not-yet-exploited issue. The practical read is that this is a high-priority patch because of impact and ease of exploitation once an attacker has any foothold, not because of confirmed active exploitation - prioritize per the act_now label while recognizing the exploitation evidence is currently absent rather than confirmed. Note also that the description is a generic bundled-hardening notice under CWE-552 and does not describe the actual trigger, so the mechanism behind the CVSS metrics is not independently verifiable from the sources.

A low-privileged authenticated user of a Splunk SOAR deployment (for example a holder of a limited analyst or API account) sends crafted requests over the network to reach files or directories that should not be externally accessible, abusing the CWE-552 weakness to read or manipulate sensitive data across a trust boundary (scope change). No user interaction is required. No public exploit code is identified at the time of analysis, and the exact trigger is not described in the available sources.