Attack ChainAIDerived
Hypothetical attack flow derived from CVE metadata – not a confirmed exploit chain
-
AccessAuthenticate as low-privilege Splunk user
-
ExploitRequest search job listings via REST API
-
ExecutionReceive improperly authorized job data
-
ImpactDisclose other users' query text and execution metadata
Vulnerability Assessment
| Weakness |
CWE
OWASP Top 10:2025
A01:2025 - Broken Access Control
ASVS 5.0
V8 - Authorization Authorization verification
MITRE ATT&CK
1 technique across 1 tactic: Defense Evasion The technique list with ATT&CK links and the kill-chain view is part of the Basic plan and up. |
| Exploitation Conditions | Requires a valid authenticated Splunk account that does NOT hold the 'admin' or 'power' role, plus network reachability to the Splunk Enterprise REST API endpoint that returns search job listings. No special non-default configuration or user interaction is needed - the flaw stems from the REST API failing to fully enforce per-user authorization before including other users' job information. The principal limiting factor is the authentication requirement (PR:L): an attacker must first obtain any low-privilege account, so this is primarily an insider or post-credential-compromise exposure rather than a remote-unauthenticated one. Affected: Splunk Enterprise below 10.4.3, 10.2.7, 10.0.10, and 9.4.15. |
| Impact | This is a genuine but low-severity information-disclosure issue, not a top-tier priority. The CVSS 3.1 vector (AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N, base 4.3, MEDIUM) is internally consistent with the description: a network-reachable REST API, low attack complexity, and - critically - PR:L, meaning the attacker must already hold a valid authenticated Splunk account (just not the 'admin' or 'power' role). Impact is confined to confidentiality (C:L) with no integrity or availability effect, matching the CWE-285 improper-authorization root cause. No EPSS score, CISA KEV listing, or public POC is present in the supplied intelligence, so exploitation status is 'no public exploit identified at time of analysis'; absence of these signals is expected for a freshly disclosed, low-impact flaw and should not be read as safety. The main caveat is tagging: the input carries an 'Authentication Bypass' tag, but this is an AUTHORIZATION bypass (CWE-285) against already-authenticated low-privilege users - verify terminology before using that tag for detection or correlation. Net: a real but modest insider/low-privilege data-leak risk, appropriately patched rather than emergency-grade. |
| Exploit ScenarioDerived | A low-privilege Splunk user (or an attacker who has phished/obtained any non-admin account) queries the search-job-listing REST API and receives search query text and job metadata belonging to other users - including job IDs, dispatch parameters, result counts, and execution metadata. This can leak sensitive search logic, data-source names, or operational detail from higher-privileged users' jobs. No public exploit code is identified at time of analysis, and exploitation requires a valid authenticated session. |
Get an e-mail when this CVE is exploited, patched or re-scored. Free account.
Alert meAnalysisAIv1 – Oct 07, 2026
Splunk Enterprise deployments below 10.4.3, 10.2.7, 10.0.10, and 9.4.15 leak other users' search activity to any authenticated user who does not hold the admin or power role, exposing search query text, job identifiers, dispatch parameters, result counts, and execution metadata through the REST API endpoint that lists search jobs. The flaw is an authorization enforcement gap: the listing API does not fully apply per-user checks before including job information belonging to other accounts, so an attacker with any low-privileged credentials can read searches they should never see. Scored CVSS 4.3 (AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N), it is a low-severity confidentiality issue with no public exploit identified at time of analysis; because a valid account with PR:L is required, the practical exposure is an insider or post-credential-compromise scenario rather than a remote-unauthenticated attack.
RemediationAI
Upgrade to a fixed release: Splunk Enterprise 10.4.3, 10.2.7, 10.0.10, or 9.4.15 on the corresponding maintenance branch, per the vendor advisory at https://advisory.splunk.com/advisories/SVD-2026-1001; the vendor reports a patch is available, so this is the primary and preferred fix and requires a restart of Splunk services. If immediate upgrading is not possible, compensate by auditing and trimming low-privilege roles so that only trusted accounts can reach the search job listing REST endpoints, and by removing the reporting/search REST capabilities from roles that do not require them - trade-off: over-restricting may break legitimate dashboards, scheduled searches, or automation that enumerate jobs. Restrict network reachability to the Splunk management port (8089) so that only trusted hosts and users - not broad corporate networks or guest segments - can query the REST API, accepting that this complicates distributed search or external integrations. Review authentication hygiene (strong passwords, MFA where supported, removal of stale or shared low-privilege accounts) to reduce the chance an attacker obtains the PR:L foothold this flaw depends on, and monitor REST logs and the Splunk audit trail for enumeration of job listings by non-admin or non-power users, understanding that such detection is a monitoring control, not a substitute for patching.
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 issue is rooted in CWE-285 (Improper Authorization), specifically a missing or incomplete per-user access check inside a search job listing endpoint implemented as a REST API. Splunk Enterprise's search subsystem records rich metadata about every dispatched search job - the SPL query text, job/sid identifiers, dispatch parameters, result counts, and execution timing - and exposes this through REST resources used to enumerate and monitor jobs. Correct behavior would scope that listing to jobs the requesting user owns or is entitled to view; instead, the API returns job records belonging to other users to any caller who lacks the admin or power roles, which are the roles normally assumed to carry broad visibility. The affected product is identified by the CPE cpe:2.3:a:splunk:splunk_enterprise:*:*:*:*:*:*:*:*, mapped by the European vulnerability database as ENISA EUVD-2026-94627 with ranges 10.2 < 10.2.7, 10.0 < 10.0.10, 10.4 < 10.4.3, and 9.4 < 9.4.15. Because the CVSS vector carries PR:L, the attacker must already hold a valid Splunk account; no user interaction (UI:N) or non-default configuration is required, and the confidentiality impact is limited to metadata and query text rather than indexed event data itself.
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:L/I:N/A:N
Network-reachable REST API (AV:N), no special conditions (AC:L), but a valid non-admin account is required (PR:L); only limited metadata/query disclosure, so C:L and I:N/A:N.
Primary rating from Vendor (cisco).
CVSS VectorVendor: cisco
Lifecycle Timeline
2DescriptionCVE.org
In Splunk Enterprise versions below 10.4.3, 10.2.7, 10.0.10, and 9.4.15, a user who does not hold the "admin" or "power" Splunk roles could access search query text and job metadata for jobs that belong to other users, including job identifiers, dispatch parameters, result counts, and execution metadata, through an Application Programming Interface (API) implemented as a Representational State Transfer (REST) API. The vulnerability is possible because the REST API does not fully enforce per-user authorization before it includes job information in search job listings.
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-94627
GHSA-xr6j-h3xr-6fhg
NVD
CVE.org
EPSS
Vulnrichment
Exploit-DB