EUVD-2026-107655
GHSA-6j5x-xq56-rxx3
Attack ChainAIDerived
Hypothetical attack flow derived from CVE metadata – not a confirmed exploit chain
-
AccessAuthenticate as low-privilege Splunk user
-
ExploitAccess sourcetype renaming operation via Splunk Web
-
ExecutionSubmit config change targeting unauthorized app
-
ImpactAlter/delete sourcetype rename configuration
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 | Exploitation requires that Splunk Web be turned on (enabled), because the missing permission check resides in the Splunk Web code path for sourcetype renaming operations - deployments running without Splunk Web are not affected via this vector. The attacker must also hold a valid, authenticated Splunk account (PR:L) that lacks the 'admin' and 'power' roles; fully unauthenticated exploitation is not possible. Impact is limited to integrity of sourcetype renaming configurations in apps the user cannot legitimately access - there is no confidentiality or availability impact. Upgrading to Splunk Enterprise 10.4.4, 10.2.8, 10.0.11, or 9.4.16 (or later) remediates the issue. |
| Impact | This is a genuinely low-priority issue despite affecting a widely-deployed product. The provided CVSS 3.1 vector (AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:L/A:N) scores 4.3 (Medium) and is internally consistent with the description: a network-reachable but authenticated (PR:L) attacker with a low-privilege Splunk account can only affect integrity (I:L), with no confidentiality or availability impact. The vulnerability (CWE-862, Missing Authorization) lets a non-admin/non-power user manipulate sourcetype renaming configurations in apps they should not access - a horizontal privilege/authorization boundary issue, not full compromise. No EPSS score, KEV listing, or POC was provided in the input; exploitation status is therefore 'no public exploit identified at time of analysis.' No signals conflict, but several are simply absent: there is no EPSS probability to gauge likelihood and no KEV confirmation of active use. The scoped, low-integrity-only impact combined with a required authenticated foothold means this is a real-but-minor hardening fix rather than an urgent emergency - prioritize it in normal patch cycles, not as a break-glass response. Note the input tag labels this 'Authentication Bypass,' but the CWE (862) and description describe an authorization (access-control) failure for already-authenticated users, not authentication bypass - verify framing with the Splunk advisory. |
| Exploit ScenarioDerived | An attacker who already holds a low-privilege Splunk Enterprise account (lacking the admin or power roles) uses Splunk Web to create, move, edit, or delete sourcetype renaming configurations belonging to an app they were never granted access to. Because Splunk Web omits the app-permission check before performing these operations, the attacker can tamper with other apps' data-labeling configuration, potentially disrupting how events are categorized at search time. No public exploit code was identified in the provided data. |
Get an e-mail when this CVE is exploited, patched or re-scored. Free account.
Alert meAnalysisAIv1 – Oct 21, 2026
Missing authorization checks in Splunk Web's search-time sourcetype renaming feature let authenticated users who lack the admin and power roles create, move, edit, or delete their own sourcetype renaming configurations inside apps they are not permitted to access. Splunk Enterprise deployments below 10.4.4, 10.2.8, 10.0.11, and 9.4.16 are affected, but only when Splunk Web is enabled, since the missing permission check lives in that code path. Impact is limited to the integrity of renaming configurations in otherwise inaccessible apps - no confidentiality or availability effect - giving this a low CVSS of 4.3 (PR:L, I:L); no public exploit code was identified at time of analysis, so this is a genuinely low-priority issue despite affecting a widely deployed product.
RemediationAI
Upgrade Splunk Enterprise to 10.4.4, 10.2.8, 10.0.11, or 9.4.16 (or later) - these are the vendor-released fixed versions per advisory SVD-2026-1007 (https://advisory.splunk.com/advisories/SVD-2026-1007). Until the upgrade is applied, reduce exposure by disabling Splunk Web on instances that do not require the UI (trade-off: users lose browser-based administration and must rely on the CLI/REST API), by reviewing and tightening role assignments so that only trusted accounts hold non-default roles capable of managing apps (trade-off: administrative overhead and possible disruption to existing workflows), and by auditing apps for unexpected sourcetype renaming configurations to detect tampering. Additionally, restrict network access to Splunk Web to trusted management networks, since the vulnerable code path is only reachable through the web interface.
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
The root cause is CWE-862 (Missing Authorization). Splunk Enterprise stores search-time sourcetype renaming configurations within apps, and access to those apps is normally gated by role-based permissions; the Splunk Web handler that performs create/move/edit/delete operations on a user's own renaming stanzas fails to verify that the requester holds the required permissions on the target app. Because the flaw sits in the Splunk Web code path rather than in the search-time configuration layer itself, deployments with Splunk Web disabled do not expose this vector. The attacker must already be an authenticated Splunk user holding a role below admin or power (CVSS PR:L), and the resulting impact is purely integrity-based (I:L) against configuration objects the user should not be able to touch - no read of protected data and no service disruption. CPE data (cpe:2.3:a:splunk:splunk_enterprise) confirms the affected product family is Splunk Enterprise across the 9.4, 10.0, 10.2, and 10.4 release trains.
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:L/A:N
Splunk Web is network-reachable (AV:N) and attack is reliable (AC:L); a low-privilege authenticated account is required (PR:L); only configuration integrity is affected (I:L, C:N, A:N).
Primary rating from Vendor (cisco).
CVSS VectorVendor: cisco
Lifecycle Timeline
2DescriptionCVE.org
In Splunk Enterprise versions below 10.4.4, 10.2.8, 10.0.11, and 9.4.16, a user who does not hold the "admin" or "power" Splunk roles could create, move, edit, or delete sourcetype renaming configurations that they own in apps that they do not have permission to access. The vulnerability is possible when Splunk Web is turned on because Splunk Web does not verify the required app permissions before it performs sourcetype renaming operations. For more information see Rename source types at search time (https://help.splunk.com/en/splunk-enterprise/get-started/get-data-in/10.6/configure-source-types/rename-source-types-at-search-time) in the Splunk documentation.
Threat Intelligence Overview
NVD
CVE.org
EPSS
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
Exploit-DB