Splunk Enterprise CVE-2026-76278

Exploitation requires an authenticated user whose assigned role includes the edit_spl2_module_permissions capability, plus network access to the Splunk Enterprise REST management API; the attacker then requests SPL2 module permission grants for an app they lack read permission on, and the API returns them because it omits the app-read authorization check. Limiting factors: the specific capability is a privileged grant not held by ordinary users, only Splunk Enterprise 10.0.x/10.2.x/10.4.x below the fixed releases are affected (9.4.x is explicitly not affected), and the impact is limited to disclosure of permission-grant metadata with no write or availability effect.

This is a genuinely low-priority issue despite being a real authorization flaw. The CVSS 3.1 base score of 4.3 (vector AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N) is accurate and well-constrained: network-reachable and low-complexity, but it requires an authenticated user who already holds a role with the edit_spl2_module_permissions capability (PR:L), and the only impact is a low-confidentiality information disclosure (C:L; I:N/A:N). There is no integrity or availability impact and no privilege escalation - the attacker merely reads SPL2 module permission grants for apps they cannot otherwise view (CWE-639, an IDOR/authorization-bypass pattern). No EPSS score was provided, the CVE is NOT on CISA KEV, and no public POC is indicated, so exploitation status is: no public exploit identified at time of analysis. The signals are internally consistent - there is no network-vs-local conflict, and the required capability is a meaningful limiting factor. Overall this is a high-trust, low-severity finding that should be patched during normal maintenance cycles rather than treated as an emergency; it is not a high-CVSS-but-low-risk inflation case, it is simply a correctly-scored minor issue.

An authenticated Splunk Enterprise user who has been granted a role carrying the edit_spl2_module_permissions capability sends a crafted request to the affected REST API endpoint referencing SPL2 modules in an app they are not authorized to read. Because Splunk fails to verify read access to the target app before returning data, the API discloses the permission grants for those SPL2 modules. No public exploit code is identified; realistic exploitation requires the attacker to already hold the specific capability and network access to the management interface.