Splunk Enterprise CVE-2026-76336

The attacker must hold a valid Splunk Enterprise account that does NOT have the 'admin' or 'power' role - any lower-privileged authenticated user qualifies. The target instance must be running Splunk Enterprise version 10.2.x (below 10.2.6) or 10.4.x (below 10.4.1), and the SPL2 module management REST API must be accessible (default Splunk management port 8089 over HTTPS). Instances running Splunk Enterprise below 10.2.0 are not affected as the SPL2 module API is absent. Exploitation is limited by the requirement for a valid credential and network access to the management API port; unauthenticated external attackers cannot exploit this directly.

The CVSS 3.1 vector (AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:H/A:L) accurately reflects the threat: network-exploitable by any authenticated low-privileged user with no complexity barrier, resulting in high integrity impact and low availability impact. There is no confidentiality exposure. No EPSS data was provided in the intelligence package, and this CVE does not appear in CISA KEV, indicating no confirmed widespread active exploitation at time of analysis. The practical risk is significant despite the absence of a public exploit: Splunk Enterprise environments typically host many low-privileged analyst accounts, meaning the attack surface within an organization is broad - any authenticated user becomes a potential threat actor. The integrity impact is severe because SPL2 module deletion is irreversible without backups, potentially destroying production saved searches, exported datasets, and shared functions enterprise-wide. The lack of availability impact beyond 'partial' reflects that the Splunk platform continues running; only SPL2-dependent workflows break. Reported by Cisco, with a vendor advisory available, so the finding is credible and well-sourced.

An attacker with any valid Splunk account - such as a low-privileged analyst or a compromised service account - issues an authenticated HTTP DELETE request to the SPL2 module management REST API endpoint targeting all modules, without supplying admin or power role credentials. The API processes the request without proper authorization checks, deleting all SPL2 modules instance-wide across all apps and users. No public exploit code has been identified at time of analysis, but the attack requires only standard HTTP tooling and a valid low-privilege credential.