Splunk Enterprise CVE-2026-76263

An attacker must hold a valid Splunk Enterprise account that lacks the 'admin' or 'power' role - any standard authenticated user qualifies. The target deployment must be running Splunk Enterprise 10.2.x or 10.4.x (versions below 10.2 are explicitly not affected as SPL2 is absent). The data management orchestrator must be in use and SPL2 modules must exist to target; environments that have not adopted SPL2-based apps have no attack surface. Exploitation is bounded by authentication (PR:L in CVSS) - unauthenticated external attackers cannot exploit this directly. The primary limiting factors are the authentication prerequisite and the requirement for an affected version branch.

The CVSS 3.1 base score of 5.4 (Medium) is grounded in a network-reachable vector (AV:N), low complexity (AC:L), low-privilege requirement (PR:L), no user interaction (UI:N), and bounded impact (C:N/I:L/A:L). The integrity impact reflects the ability to delete another user's modules; the availability impact reflects that those modules become permanently unavailable. No EPSS data was provided, but the combination of required authentication, absence from CISA KEV, and no known POC collectively suggest opportunistic exploitation is unlikely in the near term. The practical threat model is an insider or a compromised low-privilege account performing targeted sabotage of another user's SPL2 work, not mass unauthenticated exploitation. The flaw is not exploitable against Splunk Enterprise versions below 10.2 because SPL2 modules and the orchestrator interface were not yet present. Overall this is a genuine medium-priority remediation - patch promptly but it does not warrant emergency response absent evidence of active abuse.

An authenticated Splunk user without the admin or power role enumerates or guesses the resource identifiers of SPL2 modules belonging to colleagues or service accounts, then issues deletion requests to the data management orchestrator API supplying those IDs. Because the orchestrator performs no ownership validation, the requests succeed and the targeted modules are permanently removed, disrupting data pipelines or applications that depend on them. No public exploit code is known at time of analysis, but the attack requires only standard HTTP tooling and a valid low-privileged session.