Splunk Enterprise EUVD-2026-94622

Exploitation requires an authenticated Splunk account assigned a role that holds the specific list_spl2_modules capability, and the attacker must reach the SPL2-module-filtering REST API endpoint over the network. The core prerequisite is the SPL2 module management feature being in use with multiple users owning private module definitions - in a single-user or no-SPL2-module deployment there is little to disclose. Limiting factors: the required list_spl2_modules capability (not granted to default unprivileged users), the confidentiality-only impact (no write/integrity or availability effect), and the fixed ceiling of versions below 10.4.3 (10.2.x, 10.0.x, and 9.4.x are explicitly not affected). Impact is bounded to data exposed through the affected REST API, specifically other users' private SPL2 module definitions.

This is a moderate, authenticated information-disclosure flaw rather than a top-tier emergency. The CVSS 3.1 vector (AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N, base 6.5) is internally consistent with the description: network-reachable REST API, low attack complexity, but requiring a pre-existing authenticated role that holds the list_spl2_modules capability (PR:L), and the impact is confined to confidentiality (C:H, I:N, A:N) - reading private SPL2 module definitions belonging to other users via SQL injection in module filtering (CWE-89). No EPSS score, KEV listing, or public POC was provided in the input, so exploitation likelihood cannot be quantified; status is 'no public exploit identified at time of analysis.' The main signal tempering risk is the privilege requirement - this is not an unauthenticated internet-facing bug but a privilege-boundary/tenant-isolation break usable by an existing low-privileged (but SPL2-capable) user or an attacker who has already compromised such an account. A patch is confirmed available from the vendor. Net: a real priority for multi-tenant/shared Splunk deployments where SPL2 module confidentiality matters, but lower urgency than an unauthenticated RCE. Note the description states Splunk Cloud Platform is also affected, whereas the provided CPE lists only splunk_enterprise - verify Cloud exposure separately.

An attacker who already holds (or has phished/compromised) a Splunk role carrying the list_spl2_modules capability sends crafted input to the SPL2 module filtering REST API endpoint. Because user-supplied values are not parameterized before use in the backend database query, the attacker injects SQL that bypasses per-user permission filtering and returns private SPL2 module definitions owned by other users. No public exploit code was identified at time of analysis, and the attack is remote but authenticated (PR:L).