Splunk SOAR EUVD-2026-107644

Exploitation requires an authenticated account that holds a role granting the 'Users and Roles view' permission in Splunk SOAR (On-premises) below 8.7.0; this is the exact precondition. The mechanism is the REST API accepting caller-controlled query filters on sensitive user-record fields, which lets the caller infer other users' authentication token values. Full administrative compromise is further conditional on at least one inferred token belonging to an administrator - so impact is limited where the vulnerable permission is granted only to already-trusted admins, where least-privilege roles do not exist, or in single-admin deployments. Limiting factors: requires valid authentication plus the specific view permission (no anonymous/pre-auth access), on-premises REST API reachability, and successful inference of a privileged token.

This is a privilege-escalation-via-information-disclosure flaw (CWE-200) in Splunk SOAR below 8.7.0, rated 7.2 (High) by the vendor using CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:H/I:H/A:H. The signals point to a real but gated risk rather than a mass-exploitation emergency: the attack is network-reachable (AV:N) and low-complexity (AC:L) through the REST API, but it is NOT unauthenticated - the vendor vector sets PR:H, and the description confirms the attacker must already hold a role carrying the 'Users and Roles view' permission, so this is an insider / compromised-privileged-account escalation path, not an external pre-auth break. No EPSS score, CISA KEV entry, or public POC was provided in the intelligence set, so there is no evidence of active exploitation or widespread automated attack; the risk is driven by the high technical impact (full admin takeover of the SOAR instance) rather than by exploitation likelihood. One point of tension worth flagging: the vendor's PR:H appears conservative - 'Users and Roles view' is a single granted view permission rather than full administrative access, which arguably maps to PR:L and a higher adjusted score (see assessed vector). The impact is also somewhat conditional ('if the inferred token grants administrative access'), meaning worst-case C:H/I:H/A:H only materializes when an admin token is successfully inferred. Net: a legitimate patch priority for any multi-tenant or least-privilege SOAR deployment where non-admin roles exist, but lower urgency where only trusted administrators hold the relevant permission.

A low-trust SOAR operator (or an attacker who has phished/compromised such an account) who holds a role with the 'Users and Roles view' permission queries the REST API with crafted filters on sensitive user-record fields to infer other users' authentication token values. By inferring a token that belongs to an administrator, the attacker reuses it to gain full administrative control of the Splunk SOAR instance. No public exploit was identified at time of analysis, so this would require manual crafting of the filter-based inference.