Attack ChainAIDerived
Hypothetical attack flow derived from CVE metadata – not a confirmed exploit chain
-
AccessObtain low-privileged Splunk credentials
-
DeliveryReach Splunk REST API on port 8089
-
ExploitSend authenticated DELETE request to SPL2 module management endpoint
-
ExecutionAPI skips authorization check
-
PersistAll SPL2 modules deleted instance-wide
-
ImpactSPL2-dependent searches and exports disrupted
Vulnerability Assessment
| Weakness |
CWE
OWASP Top 10:2025
A01:2025 - Broken Access Control
ASVS 5.0
V8 - Authorization Authorization checks on every request
MITRE ATT&CK
1 technique across 1 tactic: Privilege Escalation The technique list with ATT&CK links and the kill-chain view is part of the Basic plan and up. |
| Exploitation Conditions | 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. |
| Impact | 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. |
| Exploit ScenarioDerived | 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. |
Get an e-mail when this CVE is exploited, patched or re-scored. Free account.
Alert meAnalysisAIv1 – Aug 19, 2026
Insufficient authorization in Splunk Enterprise's SPL2 module management REST API allows any authenticated low-privileged user - one without the 'admin' or 'power' role - to delete all SPL2 modules across every app and user on the instance. Affected versions are 10.2.x through 10.2.5 and 10.4.x through 10.4.1; versions below 10.2 are unaffected as SPL2 module management did not exist there. The resulting impact is high integrity loss (permanent deletion of exported datasets and functions) and partial service disruption, with no patch-confirmed active exploitation at time of analysis.
RemediationAI
Upgrade Splunk Enterprise to version 10.4.2 or 10.2.6, which contain the fix per the vendor advisory at https://advisory.splunk.com/advisories/SVD-2026-0801. If immediate patching is not possible, restrict network access to the Splunk REST API port (default 8089) at the firewall or network layer, limiting it to only trusted management hosts - this does not eliminate the risk from internal low-privileged users but reduces the external attack surface. Additionally, audit current SPL2 module permissions using the Splunk documentation references provided (https://help.splunk.com/en/splunk-enterprise/search/spl2-search-manual/modules-statements-and-views/module-permissions) and ensure module backups exist. Note that restricting the REST API port may break integrations relying on the Splunk management API, so test in a staging environment first.
Affected VersionsENISA
Affected Packages
Source: OSV (Open Source Vulnerabilities)
Affects your stack
Affects 1 package in euvd
Checking this CVE against your own stacks and servers is part of the Basic plan and up.
Technical ContextAI · show details
Splunk Enterprise's SPL2 (Search Processing Language 2) introduces a module system for reusable search logic, exposed via a dedicated REST API for module management. The vulnerability maps to CWE-862 (Missing Authorization): the REST API endpoint responsible for module deletion performs insufficient privilege checks, failing to verify that the requesting user holds an administrative or power role before executing destructive cross-user, cross-app operations. The affected CPE is cpe:2.3:a:splunk:splunk_enterprise:*:*:*:*:*:*:*:*, scoped to version ranges 10.2.x and 10.4.x. The SPL2 module layer is a relatively recent addition to Splunk Enterprise, explaining why only these version branches are affected.
Know when Splunk gets its next vulnerability
- Watch products and get an email when something new is published
- Check this CVE against your own stack and servers
- Exploit and PoC references, threat intelligence from 22 sources
No credit card · 7-day full trial
Severity by source
AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:H/A:L
Network REST API, no complexity barrier, requires only low-privilege authentication; integrity impact is high (mass deletion), availability low, no confidentiality impact.
Primary rating from Vendor (cisco).
CVSS VectorVendor: cisco
Lifecycle Timeline
2DescriptionCVE.org
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 all Search Processing Language 2 (SPL2) modules across all apps and users on the instance through the SPL2 module management Representational State Transfer (REST) API. This could delete exported datasets and functions, affect system integrity, and cause partial service disruption. The vulnerability does not affect Splunk Enterprise versions below 10.2. The vulnerability is possible because the SPL2 module management REST API does not sufficiently authorize and validate module deletion requests. For more information see Manage SPL2 modules (https://help.splunk.com/en/splunk-enterprise/search/spl2-search-manual/multiple-searches-in-an-spl2-module/manage-spl2-modules) and Module permissions (https://help.splunk.com/en/splunk-enterprise/search/spl2-search-manual/modules-statements-and-views/module-permissions) in the Splunk documentation.
Executive ViewAI
Splunk Enterprise versions 10.2.x through 10.2.5 and 10.4.x through 10.4.1 contain an authorization bypass allowing any low-privileged authenticated user to permanently delete critical datasets and functions across the entire instance. This creates significant risk for organizations depending on Splunk for analytics and reporting, with potential for malicious insiders or compromised accounts to disrupt business operations and data integrity.
Apply vendor patch.
Threat Intelligence Overview
How this decision was reached
The engine reads each signal below and applies a fixed list of rules from top to bottom. The first rule that matches sets the recommended action – like a statement, every line is shown.
What every action level means
SSVC AssessmentENISA
Priority Score
Attack Technique
Authentication bypass attacks exploit flaws in the verification mechanisms that control access to systems and applications.
The (1) TLS and (2) DTLS implementations in OpenSSL 1.0.1 before 1.0.1g do not properly handle Heartbeat Extension packe
Unauthenticated arbitrary file write in Splunk Enterprise (below 10.2.4 and 10.0.7) and Splunk Cloud Platform (below 10.
curl 7.75.0 through 7.76.1 suffers from a use-after-free vulnerability resulting in already freed memory being used when
curl < 7.84.0 supports "chained" HTTP compression algorithms, meaning that a serverresponse can be compressed multiple t
In Splunk Enterprise versions below 9.2.2, 9.1.5, and 9.0.10, a low-privileged user that does not hold the admin or powe
In Splunk Enterprise versions below 9.0.7 and 9.1.2, Splunk Enterprise does not safely sanitize extensible stylesheet la
In versions of Splunk Enterprise below 9.0.5, 8.2.11, and 8.1.14, and Splunk Cloud Platform below version 9.0.2303.100,
In Splunk Enterprise versions below 8.2.9, 8.1.12, and 9.0.2, an authenticated user can execute arbitrary code through t
When curl < 7.84.0 saves cookies, alt-svc and hsts data to local files, it makes the operation atomic by finalizing the
SQLite 1.0.12 through 3.39.x before 3.39.2 sometimes allows an array-bounds overflow if billions of bytes are used in a
A vulnerability exists in curl <7.87.0 HSTS check that could be bypassed to trick it to keep using HTTP. Rated high seve
When doing HTTP(S) transfers, libcurl might erroneously use the read callback (`CURLOPT_READFUNCTION`) to ask for data t
EUVD-2026-62901
GHSA-cg88-8x7g-8rf5
NVD
CVE.org
EPSS
Exploit-DB