Splunk SOAR EUVD-2026-107643

Exploitation requires an already-authenticated Splunk SOAR (On-premises) account with REST API access on a version below 8.7.0; the attacker invokes the REST endpoint that manages the Enterprise Security edition, where SOAR performs authentication but omits the authorization check before applying the license change. Limiting factors: valid credentials are mandatory (PR:L, so not exploitable by fully unauthenticated outsiders), the target must be an on-premises SOAR instance below 8.7.0, and impact is confined to unauthorized license/edition modification rather than data access or service disruption.

This is a moderate-severity authorization flaw (CVSS 6.5) rather than a top-tier emergency. The CVSS 3.1 vector (AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:H/A:N) shows a network-reachable, low-complexity issue that nonetheless requires an already-authenticated low-privileged account (PR:L), which meaningfully narrows the attacker population to insiders or anyone who has already obtained valid SOAR credentials. The sole impact is to integrity (I:H) - unauthorized modification of the Enterprise Security edition/license state - with no confidentiality or availability loss claimed, so this is a privilege/authorization-scope problem (CWE-862, missing authorization), not remote code execution or data theft. No EPSS score, CISA KEV listing, POC, or SSVC decision data was provided in the input, so exploitation probability and automatability cannot be quantified from the available signals. Note a labeling conflict: the input Tags include 'Authentication Bypass,' but the description and CWE-862 make clear this is an AUTHORIZATION (not authentication) failure - the system authenticates the caller but fails to authorize the license-change action - verify tag before triaging. Overall this is a real but bounded insider/post-authentication integrity issue best patched on a normal cadence rather than treated as an active threat.

A low-privileged but authenticated Splunk SOAR user (or an attacker who has obtained any valid SOAR account) sends a crafted request to the REST API endpoint that manages the Enterprise Security edition. Because SOAR authenticates but never checks whether the caller is authorized for that action, the server applies the license/edition change the user was never permitted to make. No public exploit code was identified at time of analysis, and successful use requires valid credentials.