CVE-2026-76263: Improper Access Control through the REST API in Splunk Enterprise
In Splunk Enterprise versions below 10.4.2 and 10.2.6, a user who does not hold the "admin" or "power" Splunk roles could delete Splunk Processing Language version 2 (SPL2) modules belonging to other users through the data management orchestrator interface. The vulnerability does not affect Splunk Enterprise versions below 10.2. The broken object level authorization is possible because the data management orchestrator does not verify that the requesting user owns the target resources before it deletes the modules. For more information see Manage SPL2-based apps (https://help.splunk.com/en/splunk-enterprise/administer/admin-manual/10.4/meet-splunk-apps/manage-spl2-based-apps) in the Splunk documentation.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
Splunk Enterpriseto a version that resolves this vulnerability.Fixed in 10.4.2 - Upgrade
Upgrade
Splunk Enterpriseto a version that resolves this vulnerability.Fixed in 10.2.6 - Upgrade
Upgrade
Splunk Enterpriseto a version that resolves this vulnerability.Fixed in 10.0.9 - Upgrade
Upgrade
Splunk Enterpriseto a version that resolves this vulnerability.Fixed in 9.4.14
Event History
Frequently Asked Questions
Which deployments are affected?
Splunk Enterprise versions 10.2 through versions before 10.2.6, and versions before 10.4.2, are affected. Versions below 10.2 are not affected.
What access does an attacker need?
An attacker needs an authenticated Splunk account that does not have the admin or power role. They can use the data management orchestrator interface to target SPL2 modules owned by other users.
What is the impact of successful exploitation?
A low-privileged user can delete other users' SPL2 modules. The provided severity vector indicates integrity and availability impact, with no confidentiality impact.
What should be prioritized for remediation?
Upgrade affected Splunk Enterprise deployments to 10.2.6 or later in the 10.2 line, or to 10.4.2 or later. The issue is caused by missing ownership verification when deleting modules through the data management orchestrator.