Splunk Enterprise
Monthly
Improper neutralization weaknesses in Splunk Enterprise allow a network-positioned attacker holding a valid low-privilege account to achieve high confidentiality, integrity, and availability impact, with a scope change (S:C) indicating the effect can extend beyond the initially compromised component. Affected branches are Splunk Enterprise 9.4 before 9.4.16, 10.0 before 10.0.11, 10.2 before 10.2.8, and 10.4 before 10.4.4; CVSS 3.1 is 9.9 (AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H), so authentication is required but no user interaction is, and only the listed versions are in scope. Vendor fixes are available and the issue is prioritized act_now, but no public exploit code and no CISA KEV entry were identified at time of analysis; the two supplied references are one Splunk advisory plus an NVD detail page, so the corroborating signal quality is thin relative to the score.
Signals conflict and must be weighed carefully: Splunk Enterprise versions before 9.4.16, 10.0.11, 10.2.8, and 10.4.4 contain internally discovered protection-mechanism failures tracked as CVE-2026-76301 (CWE-693), rated CVSS 9.8 with a vector for unauthenticated network attackers and high confidentiality, integrity, and availability impact. The specific feature, protocol, configuration, trigger, and per-vulnerability impact are not disclosed in the available sources, and no public exploit was identified at time of analysis; EPSS is low at 0.17% (6th percentile). A vendor patch is available, and the vuln.today decision is act_now.
Splunk Enterprise releases 10.2 before 10.2.8, 10.0 before 10.0.11, 9.4 before 9.4.16 and 10.4 before 10.4.4 carry multiple internally discovered resource-lifetime flaws (CWE-664) that a remote attacker holding low-privileged credentials can use to gain high confidentiality, integrity and availability impact, with low attack complexity and no user interaction (CVSS 3.1 base 8.8, PR:L). Cisco/Splunk shipped the fixes in a consolidated hardening release rather than a single-feature advisory, so the specific triggering component is not described in the available sources; the only confirmed limiting factor is the need for valid low-privileged access. There is no CISA KEV entry and no confirmed working exploit code, and EPSS is low at 0.17% (6th percentile), though the vendor's this-week prioritisation and the breadth of the hardening release justify prompt upgrading.
Improper access control in Splunk Enterprise 9.4, 10.0, 10.2, and 10.4 allows a low-privileged authenticated user to cross a security boundary and achieve high confidentiality, integrity, and availability impact, making the release a 9.9 severity fix. The flaw was found during Cisco's internal hardening review rather than through external reporting, and the affected ranges are 9.4 before 9.4.16, 10.0 before 10.0.11, 10.2 before 10.2.8, and 10.4 before 10.4.4. No public exploit code has been identified and there is no CISA KEV entry, but vendor patch availability combined with an act_now priority label places upgraded discipline on anyone running an unpatched instance; the trigger is not described in the available sources.
Authenticated low-privileged Splunk Enterprise users can escalate to arbitrary OS command execution on search head cluster members by reconstructing the PostgreSQL sidecar superuser password. The password is deterministically derived from the search head cluster identifier, which surfaces in search job logs readable by users who do not hold the 'admin' or 'power' roles. Deployments below 10.4.4 and below 10.2.8 are affected where a search head cluster runs the PostgreSQL sidecar service; no public exploit code has been identified at time of analysis, but the flaw carries a CVSS score of 8.8 (AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H) and warrants prompt patching in SHC environments.
Remote code execution in Splunk Enterprise is possible for authenticated users whose roles include the edit_manager_xml capability; by opening a crafted Manager XML configuration in Splunk Web, they can execute arbitrary operating-system commands with the privileges of the account running Splunk Enterprise. The flaw affects versions below 10.4.3, 10.2.8, 10.0.11, and 9.4.16. No public exploit was identified at time of analysis, and the high-privilege prerequisite confines meaningful exposure to environments where edit_manager_xml is assigned broadly rather than tightly restricted to trusted administrators.
Authenticated Splunk Enterprise users whose roles include the schedule_search capability can use the scheduled search workflow to run risky SPL commands that the platform would normally block, resulting in disclosure or alteration of Splunk data or disruption of Splunk availability. The issue affects Splunk Enterprise versions below 10.4.4, 10.2.8, 10.0.11, and 9.4.16, and is fixed in those releases. The assessed vector requires low privileges (PR:L) and no user interaction, with high confidentiality, integrity, and availability impact; no public exploit identified at time of analysis.
Unauthenticated denial of service in Splunk Enterprise deployments below 10.4.4, 10.2.8, and 10.0.11 is reachable through the Edge Processor package download endpoint in the Splunk Pipeline Builders app. Repeated unauthenticated requests force the Splunk daemon to read and base64-encode the complete package in memory for each request, exhausting system resources and potentially making the service stop responding (CVSS 7.5, CWE-400). Exposure is limited to instances running Edge Processor/Pipeline Builders, and no public exploit identified at time of analysis.
Splunk Enterprise deployments running Splunk Web in versions below 10.4.4, 10.2.8, 10.0.11, and 9.4.16 can be taken offline by a single unauthenticated request to the Splunk Web JavaScript logger endpoint, which parses request headers without any limit and can be driven into an unresponsive state. Recovery requires a full restart of Splunk Enterprise, making this an easy-to-repeat availability attack against any instance whose Splunk Web port is reachable by the attacker. The assessed vector (AV:N/AC:L/PR:N/UI:N, availability-only) is consistent with a low-complexity denial of service; no public exploit code or confirmed active exploitation was identified at time of analysis, and the risk is bounded to service availability with no implied data loss or compromise.
Splunk Enterprise installations at versions below 9.4.15, 10.0.10, 10.2.7, and 10.4.3 are affected by a coding-standard defect that the vendor rates at CVSS 3.1 base 9.8 (AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H), meaning a remote, unauthenticated network attacker could in principle achieve full loss of confidentiality, integrity, and availability. The issue is one of several internally identified findings that Splunk grouped under CWE-710 (Improper Adherence to Coding Standards) and documents in advisory SVD-2026-1002; because the advisory groups multiple defects by weakness class, it does not enumerate the specific component, feature, or configuration prerequisite involved, so the exact attack path cannot be confirmed from available data. Practical risk is presently tempered: EPSS is only 0.14 percent (3rd percentile) and there is no public exploit identified at time of analysis, with no CISA KEV listing indicating confirmed active exploitation; the dominant exposure factor is network reachability to the Splunk web interface or management port, which in many enterprise deployments is restricted to internal networks rather than internet-exposed.
Improper neutralization (injection-class weakness, CWE-707) in Splunk Enterprise lets an attacker submit crafted input through a network-reachable Splunk interface and achieve high impact across confidentiality, integrity, and availability - per our independent assessment, exploitation requires low-privilege authentication (CVSS:3.1/AV:N/AC:L/PR:L/UI:N), even though the upstream NVD-style vector claims PR:N/unauthenticated. Affected are Splunk Enterprise 10.4 before 10.4.3, 10.2 before 10.2.7, 10.0 before 10.0.10, and 9.4 before 9.4.15; the vendor grouped multiple internally identified findings by CWE and assigned this CVE to the neutralization group, so the advisory names no single endpoint or feature. No public exploit code has been identified at time of analysis, EPSS is only 0.15% (4th percentile), and the vulnerability is not listed as confirmed actively exploited (CISA KEV), so urgency should be driven by the critical severity and the accessibility of the affected interface rather than by observed exploitation.
Authenticated information disclosure in Splunk Enterprise allows a low-privileged account to bypass an intended security control and access data it should not be able to reach, affecting versions below 10.4.3, 10.2.7, 10.0.10, and 9.4.15. Rated CVSS 7.6 (AV:N/AC:L/PR:L/UI:N, with high confidentiality impact but only low integrity and availability impact), the issue is classified as CWE-693, Protection Mechanism Failure, and requires only a valid Splunk account with network reachability to the instance - no user interaction is needed, but a fully unauthenticated outsider cannot exploit it. No public exploit code and no confirmed active exploitation have been identified at time of analysis, and the vendor has released fixed builds for all four affected release trains for this internally discovered flaw.
Authenticated low-privilege users with network access to the Splunk Enterprise management/web interface can abuse improper resource lifetime handling to achieve high confidentiality, integrity, and availability impact on deployments running versions below 9.4.15, 10.0.10, 10.2.7, or 10.4.3. The flaw is rated CVSS 8.8 (AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H) and is one of a group of internally discovered issues covered by Splunk advisory SVD-2026-1002, where CVEs are assigned per CWE group, so the specific vulnerable subsystem is not individually named. Real-world likelihood currently appears limited: EPSS is 0.15% (4th percentile), there is no CISA KEV listing and no public exploit identified at time of analysis, and the primary gating factor is that an attacker must already hold valid Splunk credentials or a session.
Unauthenticated remote command execution in Splunk Enterprise search head cluster members allows any network-reachable attacker to run operating-system commands as the Splunk service account. The flaw (CWE-306) is that the Patroni REST API exposed on a search head cluster member performs critical configuration operations without requiring authentication, so an attacker who can reach that interface can invoke it directly - no credentials needed. Only deployments running search head clustering on Splunk Enterprise versions below 10.4.3 or below 10.2.7 are exposed; 10.0.x and 9.4.x are explicitly unaffected. CVSS 3.1 base 9.8 (AV:N/AC:L/PR:N/UI:N/C:H/I:H/A:H) reflects a maximum-severity, low-complexity path with full confidentiality, integrity and availability impact, and no public exploit code or confirmed active exploitation has been identified at time of analysis, so exposure is driven mainly by whether the Patroni REST API port is reachable from untrusted networks.
Local privilege escalation in Splunk Enterprise on Linux (versions below 10.4.3, 10.2.7, 10.0.10, and 9.4.15) allows an attacker who can already run commands as the OS account running Splunk Enterprise to inject operating-system commands into installation content that a subsequent root-privileged Linux package upgrade will execute as root. The flaw is conditional: the attacker must modify the installation and then a privileged package upgrade must occur, so there is no at-will escalation. No public exploit or confirmed active exploitation was identified at time of analysis.
Unauthenticated remote disclosure of Edge Processor pipeline configurations in Splunk Enterprise 10.4.x exposes potentially sensitive data-processing logic to any network-accessible attacker. The REST API endpoint serving Edge Processor configuration lacks authentication controls (CWE-306), meaning any unauthenticated actor can retrieve pipeline details when the Edge Processor feature is enabled. No public exploit code has been identified at time of analysis, and the flaw is restricted to the 10.4.x branch - prior versions are unaffected.
Search Head Clustering bundle replication in Splunk Enterprise fails to validate bundle filenames or neutralize NUL bytes before constructing file system paths on non-captain cluster members, allowing any authenticated low-privileged user to delete or temporarily overwrite files accessible to the Splunk service account via a crafted REST API request. Affected are Splunk Enterprise versions below 10.4.2, 10.2.6, 10.0.9, and 9.4.14 running in SHC deployments - standalone instances are not in scope. No public exploit code has been identified at time of analysis and this CVE is not listed in CISA KEV; however, vendor patch is available via advisory SVD-2026-0801 and the low privilege barrier makes this a credible insider or stolen-credential threat in SOC environments.
Privilege escalation in Splunk Enterprise allows any authenticated low-privileged user to create or modify scripted lookups through improperly guarded generic transforms configuration endpoints, gaining code execution under the Splunk service account's operating system permissions. Affected versions span four release branches: 9.4.x below 9.4.14, 10.0.x below 10.0.9, 10.2.x below 10.2.6, and 10.4.x below 10.4.2. An attacker holding any valid Splunk account - without requiring the 'admin' or 'power' roles - can abuse this to access all Splunk-indexed data and compromise system integrity and availability. No public exploit or CISA KEV listing has been identified at time of analysis.
Splunk Secure Gateway's failure to validate decoded report notification identifiers enables any authenticated low-privileged user to hijack system-level REST API sessions in Splunk Enterprise, achieving full configuration control and credential theft without requiring admin or power role. Affected versions span multiple Splunk Enterprise branches (9.4.x, 10.0.x, 10.2.x, 10.4.x) and Splunk Secure Gateway branches (3.8.x, 3.9.x, 3.10.x). No public exploit code or CISA KEV listing has been identified at time of analysis, but the low-complexity, low-privilege attack path and high-impact outcome (C:H/I:H/A:H) make this a realistic internal threat in any multi-tenant or shared Splunk deployment.
Privilege escalation in Splunk Enterprise allows any user holding the schedule_search capability to execute arbitrary SPL commands with system-level privileges on the search head by configuring PDF attachments in the email alert action workflow. The flaw exists because the search scheduler substitutes a system-level authentication context for the alert owner's context during PDF rendering, effectively granting the authenticated user full system access. Affected are all Splunk Enterprise installations across the 9.4, 10.0, 10.2, and 10.4 release branches below the patched versions; no public exploit or CISA KEV listing is identified at time of analysis.
Path traversal in Splunk Enterprise allows low-privileged authenticated users to write dispatch metadata to arbitrary locations on the host filesystem by supplying a crafted search identifier to a REST API endpoint. Affected branches span versions below 10.4.2, 10.2.6, 10.0.9, and 9.4.14, covering all currently maintained Splunk Enterprise release lines. No public exploit has been identified at time of analysis and the vulnerability is absent from CISA KEV, but the low complexity, network accessibility, and high integrity impact create meaningful risk on unpatched instances, particularly given the potential for filesystem write primitives to be chained into privilege escalation.
Authentication bypass in Splunk Enterprise across multiple supported version branches allows an attacker who has obtained a trusted distributed search private key to forge administrative session tokens entirely over the network. Affected versions span 9.4.x below 9.4.14, 10.0.x below 10.0.9, 10.2.x below 10.2.6, and 10.4.x below 10.4.2. Once a forged token is accepted, the attacker gains full confidentiality, integrity, and availability impact equivalent to an administrator - including access to all indexed data and the ability to disrupt search services. No public exploit or CISA KEV listing exists at time of analysis; this was reported by Cisco, suggesting coordinated disclosure from security research.
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.
Authenticated low-privilege code injection in Splunk Enterprise allows OS command execution on the host system as the Splunk process account. Affected versions span four active release lines (9.4.x, 10.0.x, 10.2.x, 10.4.x), and the root cause is a missing capability check: Splunk Web accepts Splunk Web Manager XML configuration writes without enforcing the edit_manager_xml permission, meaning any authenticated user can plant attacker-controlled content that executes when the Manager page is rendered. No active exploitation is confirmed in CISA KEV, and no public exploit code has been identified at time of analysis, but the CVSS score of 8.8 (High) and straightforward exploitation path make this a high-priority patching target for Splunk deployments.
Stored cross-site scripting in Splunk Enterprise's Dashboard Studio allows a user holding the 'power' role to persist a crafted workflow action URL that, when triggered by a separate authenticated victim, executes attacker-controlled JavaScript in the victim's browser session. All four actively maintained branches are affected: 10.4.x below 10.4.2, 10.2.x below 10.2.6, 10.0.x below 10.0.9, and 9.4.x below 9.4.14. No public exploit has been identified at time of analysis, and exploitation is constrained by a required internal 'power' role and mandatory victim social engineering, meaningfully limiting the realistic attacker population despite the high impact ratings.
SPL injection via Analytics Workspace in Splunk Enterprise allows an unauthenticated attacker to execute arbitrary Search Processing Language queries under the permissions of a phished authenticated user. Affected across four release trains - 9.4 below 9.4.14, 10.0 below 10.0.9, 10.2 below 10.2.6, and 10.4 below 10.4.2 - the flaw stems from insufficient input validation when Analytics Workspace constructs searches from URL-embedded data. No public exploit code has been identified at time of analysis, and the vulnerability is not listed in the CISA KEV catalog, though exploitation impact scales directly with the victim user's Splunk role and data access.
SPL injection in Splunk Enterprise exposes all indexed data and compromises search integrity for any low-privileged authenticated user. Specifically, users without the 'admin' or 'power' role can inject Search Processing Language commands into saved-search dispatch requests by supplying malicious time values that Splunk Enterprise fails to validate. Patch versions have been released across all supported branches; no public exploit code or CISA KEV listing has been identified at time of analysis.
Reflected SPL injection in Splunk Enterprise's Monitoring Console allows an unauthenticated attacker to execute attacker-controlled Search Processing Language commands under the permissions of a phished authenticated victim. Affected versions span four active release trains: 9.4.x below 9.4.14, 10.0.x below 10.0.9, 10.2.x below 10.2.6, and 10.4.x below 10.4.2. No public exploit or CISA KEV listing exists at time of analysis, though successful exploitation grants full read and write access to all data and actions permitted by the victim's Splunk role.
Stored cross-site scripting in Splunk Enterprise allows a 'power' role user to persist a malicious ui-tour knowledge object that executes arbitrary JavaScript in the browser of any authenticated user who visits an affected Splunk Web page. Affected are all Splunk Enterprise deployments running versions below 10.4.2, 10.2.6, 10.0.9, or 9.4.14, a broad multi-branch footprint reported via Cisco and confirmed by Splunk advisory SVD-2026-0801. No public exploit code or CISA KEV listing has been identified at time of analysis, but the CVSS 7.3 rating and high confidentiality and integrity impact scores reflect meaningful lateral risk within an enterprise's Splunk deployment.
SPL injection in Splunk Enterprise's Job Details dashboard enables a low-privileged authenticated attacker to bypass Search Processing Language risky-command safeguards by embedding a malicious search identifier in a crafted dashboard URL and phishing an authenticated victim into opening it. The injected SPL executes under the victim's permissions, potentially exposing all data accessible to that user and compromising search integrity within those bounds. No active exploitation is confirmed and no public exploit code has been identified; a vendor patch is available across all four affected release trains per advisory SVD-2026-0801.
Dashboard Studio in Splunk Enterprise (below versions 9.4.14, 10.0.9, 10.2.6, and 10.4.2) allows a low-privileged 'user'-role account to inject attacker-controlled SPL queries that execute within the authenticated session of a different, potentially higher-privileged victim user. The root cause is Dashboard Studio's failure to consistently enforce app-visibility authorization boundaries before search query options reach the search dispatch layer - a CWE-862 Missing Authorization defect. No public exploit code or active exploitation has been confirmed; a vendor patch is available across all affected branches.
Unauthenticated SPL injection in Splunk Enterprise's nearby-event search feature allows remote attackers to execute arbitrary Search Processing Language queries without authorization across versions 9.4.x, 10.0.x, 10.2.x, and 10.4.x. The root cause is a two-pronged failure: Splunk Web does not consistently escape caller-supplied values when constructing SPL for nearby-event searches, and the embedded report access endpoint accepts those crafted requests without performing the expected authorization check. No public exploit code or active exploitation (CISA KEV) has been identified at time of analysis, but the unauthenticated network vector and wide enterprise deployment of Splunk make this a priority patch.
Remote code execution in Splunk Enterprise allows any low-privileged authenticated user to execute arbitrary code by exploiting a missing authorization check in the Federated Search dispatch flow. The vulnerability stems from the platform accepting caller-controlled bundle selection without verifying the fsh_manage capability, meaning any user with basic login access can escalate to full RCE. All four active version branches (9.4.x, 10.0.x, 10.2.x, 10.4.x) are affected below their respective patch thresholds; no public exploit or CISA KEV listing has been identified at time of analysis.
Path traversal in Splunk Enterprise's lookup configuration endpoint allows any authenticated low-privileged user - without admin or power roles - to move arbitrary files readable by the Splunk service account into a user-controlled lookup table on the search head. Affected versions span four active release trains: 10.4.x below 10.4.2, 10.2.x below 10.2.6, 10.0.x below 10.0.9, and 9.4.x below 9.4.14. With a CVSS score of 8.8 and no special configuration required beyond a standard Splunk account, successful exploitation yields full confidentiality, integrity, and availability impact; no public exploit has been identified at time of analysis and the vulnerability is not listed in CISA KEV.
Stored SPL injection in Splunk Enterprise allows an unauthenticated attacker who can reach the management port to register a crafted Deployment Server client identity containing malicious Search Processing Language code, which executes when an administrator opens the Add Data forwarder workflow. All four supported major branches are affected (9.4.x, 10.0.x, 10.2.x, 10.4.x), with vendor-confirmed fixes available. No public exploit has been identified at time of analysis, but successful exploitation yields full confidentiality, integrity, and availability impact on the Splunk platform instance.
Remote code execution in Splunk Enterprise allows any authenticated low-privileged user - one without the 'admin' or 'power' role - to inject and execute arbitrary code on the Splunk platform instance via the Splunk Web Manager Configuration REST API endpoint. The root cause is a missing permission check on the REST API path governing manager configuration writes, meaning Splunk evaluates attacker-supplied configuration values without verifying the caller holds the required role. Exploitation yields full confidentiality, integrity, and availability impact on the Splunk instance; no public exploit has been identified at time of analysis.
Remote code execution in Splunk Enterprise allows any authenticated low-privilege user - one who does not hold the 'admin' or 'power' role - to execute arbitrary code by submitting crafted XML content to the Splunk Web Manager Configuration endpoint. The vulnerability combines two weaknesses: server-side evaluation of manager XML expressions without sufficient input restrictions (CWE-94), and a missing capability check on the configuration route that should gate such access. No public exploit has been identified at time of analysis, but the low attack complexity and low privilege requirement make this a high-priority remediation target across Splunk Enterprise 9.4.x, 10.0.x, 10.2.x, and 10.4.x branches.
Remote code execution in Splunk Enterprise allows any authenticated low-privilege user (without admin or power roles) to upload a malicious knowledge bundle via the REST API and force distributed search to execute it across search peers, achieving full C/I/A compromise. The root cause is a missing authorization check - the REST API endpoint for knowledge bundle uploads does not enforce the required edit_dist_peer capability, and distributed search blindly honors caller-supplied bundle selections. No public exploit or CISA KEV listing has been identified at time of analysis, but the low authentication bar (any valid Splunk account suffices) and network-accessible attack surface make this a high-priority patching target in enterprise environments.
Session material exposure in Splunk Enterprise (versions below 10.4.1, 10.2.6, 10.0.9, and 9.4.14) allows an unauthenticated attacker who can view the HTML source of any page that embeds a Splunk report to harvest session credentials and reach the underlying search data with high confidentiality and integrity impact. The flaw stems from the dispatch archive download path failing to enforce the embedded-report authorization boundary, so archived search-job data carries sensitive session material. Rated CVSS 9.4 and reported by Cisco; no public exploit is identified at time of analysis and it is not listed in CISA KEV.
Improper access control in Splunk Enterprise (versions below 10.4.2, 10.2.6, 10.0.9, and 9.4.14) allows a party holding only an embedded report token to download the dispatch archive of an embedded report's search job, exposing session material that grants access to sensitive data and the ability to affect platform integrity. The embedded-report authorization flow fails to block dispatch-archive download requests before the archive begins streaming, so the check is effectively bypassed (CWE-284). No public exploit has been identified at time of analysis, but the 9.4 CVSS score and unauthenticated network vector make this a high-priority patch.
Improper access control in Splunk Enterprise (versions below 10.4.2, 10.2.6, 10.0.9, and 9.4.14) lets anyone holding an embedded report token download the underlying search job's dispatch archive over the REST API, recover session material, and impersonate the report owner. Because embedded reports are designed to be shared with unauthenticated viewers, an attacker can read all data the owner can access and, if the owner holds the admin role, perform administrative actions. No public exploit is identified at time of analysis, but the CVSS 9.4 rating and unauthenticated network vector make this high priority.
Unauthenticated information disclosure in Splunk Enterprise 10.4.x exposes Prometheus service metrics from the Edge Processor SPL2 Preview sidecar to any network-reachable client. The sidecar's Prometheus metrics endpoint lacks authentication, allowing retrieval of runtime and build metadata without credentials. No public exploit code has been identified at time of analysis, and the vulnerability does not affect Splunk Enterprise versions below 10.4.
Splunk Enterprise for Windows exposes a startup race condition on the management port that allows a low-privileged local user to intercept authentication tokens from Splunk child processes. By pre-binding the management port before the Splunk service initializes - exploiting the absence of exclusive address binding protections on Windows - an attacker captures session tokens that can be replayed to compromise all data and system integrity accessible to the Splunk service account. No public exploit code has been identified and EPSS is 0.12% (3rd percentile), indicating low current exploitation activity; however, the vulnerability is Windows-specific and patch is available from Splunk.
The Data Model Editor in Splunk Enterprise fails to apply SPL safeguards for risky commands when executing base searches for auto-extracted fields, allowing a low-privileged attacker (non-admin, non-power role) to craft a malicious request that executes arbitrary SPL commands under a victim's authenticated session via browser-based phishing. Affected branches span four active release lines - 9.4.x below 9.4.13, 10.0.x below 10.0.8, 10.2.x below 10.2.6, and 10.4.x below 10.4.1 - confirmed by vendor advisory SVD-2026-0801. No public exploit code or CISA KEV listing has been identified at time of analysis; vendor patches are available for all affected branches.
SPL injection via Dataset Explorer in Splunk Enterprise allows an unauthenticated attacker to cause an authenticated victim to execute arbitrary Search Processing Language pipelines under that victim's own privileges. Affected versions span five concurrent release branches - 10.4 below 10.4.2, 10.2 below 10.2.6, 10.0 below 10.0.9, 9.4 below 9.4.14, and 9.3 below 9.3.14 - giving this vulnerability broad reach across common enterprise deployments. No CISA KEV listing and no public exploit code have been identified at time of analysis, but the CVSS 8.8 score, wide deployment footprint, and straightforward phishing delivery mechanism make patching urgent.
Privilege escalation in Splunk Enterprise allows an authenticated user holding the schedule_search capability to execute arbitrary SPL commands at the highest system privilege level and read every credential stored in the credential store. Affected versions span four supported release lines - below 10.4.2, 10.2.6, 10.0.9, and 9.4.14 - meaning a wide swath of unpatched deployments across all current branches are exposed. No public exploit has been identified at time of analysis and no CISA KEV listing exists, but the credential store access potential makes this a high-priority patch for any deployment where the schedule_search capability is assigned to non-administrator users.
Missing authorization in the Splunk App for Splunk Observability Cloud exposes a stored Observability Cloud access token to any authenticated Splunk user lacking the admin or power role. Affected versions of Splunk Enterprise (below 10.4.2, 10.2.6, and 10.0.9) ship REST API endpoint handlers in the Observability Cloud integration app that fail to enforce the read_o11y_content capability before proxying requests - and the stored token - to Splunk Observability Cloud. Exploitation gives the low-privileged user full read access to all data visible to that token and limited write access to Observability Cloud content. No public exploit or KEV listing has been identified at time of analysis.
Cross-Site Request Forgery combined with SPL injection in Splunk Enterprise (below 10.4.1, 10.2.5, 10.0.8, 9.4.13) and Splunk Cloud Platform lets an attacker trick a logged-in user holding the list_deployment_server capability into unknowingly executing attacker-controlled Search Processing Language searches as the privileged splunk-system-user, exposing stored credentials and indexed data. The flaw stems from Deployment Server endpoints in Splunk Web accepting unvalidated GET requests without CSRF token checks and failing to neutralize caller input before it reaches an SPL search. No public exploit has been identified at time of analysis and it is not listed in CISA KEV.
Arbitrary file write in Splunk Enterprise (versions below 10.4.1, 10.2.5, 10.0.8, 9.4.13, 9.3.14) and Splunk Cloud Platform lets a privileged user with the edit_local_apps and install_apps capabilities abuse the app-installation workflow to write files outside the target app directory into $SPLUNK_HOME/etc/ and its subdirectories. The flaw is a path traversal (CWE-22) that can be leveraged to overwrite Splunk configuration and system files, yielding high confidentiality, integrity, and availability impact. No public exploit identified at time of analysis and it is not listed in CISA KEV.
Unauthenticated arbitrary file write in Splunk Enterprise (below 10.2.4 and 10.0.7) and Splunk Cloud Platform (below 10.4.2604.3 and 10.2.2510.14) allows remote attackers to create or truncate files on the host via an unauthenticated PostgreSQL sidecar service endpoint. The CVSS 9.8 vector (AV:N/AC:L/PR:N/UI:N) reflects trivial network exploitation, and no public exploit identified at time of analysis, though the missing-auth root cause and Splunk's high-value position in enterprise SOCs makes prompt patching warranted.
Server-side request forgery in Splunk Enterprise (below 10.2.4, 10.0.7, 9.4.12, 9.3.13) and Splunk Cloud Platform lets a low-privileged authenticated user coerce the Dashboard Studio PDF export feature into issuing HTTP requests to arbitrary internal destinations. The flaw stems from a flawed prefix-match on trusted domains plus uncritical redirect-following by the PDF export service. No public exploit identified at time of analysis, and the issue is not listed in CISA KEV.
Remote code execution in Splunk Enterprise, Splunk Cloud Platform, and the Splunk Secure Gateway app allows a low-privileged authenticated user (without 'admin' or 'power' roles) to execute arbitrary Python on the server by abusing unsafe jsonpickle deserialization of App Key Value Store (KV Store) data. CVSS is 8.8 (network, low complexity, low privileges) and the issue is currently rated as no public exploit identified at time of analysis. The flaw is reported by Cisco and disclosed via Splunk advisory SVD-2026-0601.
Remote code execution in Splunk Enterprise and Splunk Cloud Platform is achievable by low-privileged users - those without the admin or power role - by uploading a malicious file to the `$SPLUNK_HOME/var/run/splunk/apptemp` directory, exploiting insufficient isolation of temporary files (CWE-377). Affected versions span Splunk Enterprise below 10.2.1/10.0.5/9.4.10/9.3.11 and multiple Splunk Cloud Platform release trains. No public exploit code has been identified and CISA has not listed this in KEV; SSVC assigns Exploitation: none and Automatable: no, indicating low immediate threat despite total technical impact.
Cross-site request forgery in Splunk Enterprise allows an unauthenticated attacker to trick a user who holds the edit_federated_providers capability into disabling all configured federated search providers, temporarily preventing federated searches from retrieving remote data. The issue affects releases below 10.4.4, 10.2.8, 10.0.11, and 9.4.16, and exploitation requires the victim to be authenticated, privileged, and induced to click a crafted link; no public exploit code was identified at time of analysis.
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.
Information disclosure in Splunk Enterprise (below 10.4.4, 10.2.8, 10.0.11, and 9.4.16) and Splunk Secure Gateway (below 3.10.12, 3.9.26, and 3.8.73) allows an authenticated user who does not hold the admin or power roles to view dashboard and report listings beyond the requested filter scope. The flaw is a low-severity (CVSS 4.3) NoSQL-style filter injection in Secure Gateway that is limited to objects the user can already access, so it widens listing visibility rather than granting access to forbidden objects. No public exploit code or CISA KEV entry was identified at time of analysis, and exposure requires that Secure Gateway be in use.
Improper authorization in the Splunk Enterprise REST API allows an authenticated user without the 'admin' or 'power' roles to relocate field extractions and field transformations into apps they are not permitted to read, because the move operation never validates destination-app access. The issue affects deployments running versions below 10.4.4, 10.2.8, 10.0.11, and 9.4.16, and carries a CVSS score of 4.3 (AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:L/A:N), reflecting a limited integrity impact with no confidentiality or availability loss. No public exploit code has been identified at time of analysis and the issue is not listed in CISA KEV, so this is a low-to-moderate priority hardening item rather than an urgent exposure, though the required credential is a low-privilege one that many environments grant broadly.
Splunk Secure Gateway exposes mobile alert notification data belonging to other users to any authenticated low-privileged account that lacks the admin Splunk role or sc_admin Secure Gateway role. The flaw is missing user-level authorization on read requests to certain Secure Gateway App Key Value Store (KV Store) REST API collections, and it affects Splunk Enterprise releases below 10.4.4, 10.2.8, 10.0.11, and 9.4.16 plus Secure Gateway releases below 3.10.12, 3.9.26, and 3.8.73. No public exploit has been identified at time of analysis, and the vendor-assigned CVSS 3.1 score is 6.5 with a confidentiality-only impact.
Denial of service in Splunk Enterprise allows a low-privileged authenticated user to render the entire instance unavailable, requiring a manual restart to restore service. The flaw is a missing resource-consumption limit in the REST API endpoint for lookup table files, which fails to bound response field selections (CWE-770). Splunk Enterprise versions below 10.4.4, 10.2.8, 10.0.11, and 9.4.16 are affected; exploitation requires only a valid Splunk account (PR:L) that need not hold the admin or power roles, and no public exploit code or active exploitation has been identified at time of analysis. Impact is strictly availability - no data confidentiality or integrity loss - making this a genuine but moderate-priority issue that escalates in environments with broad API access.
Splunk Enterprise deployments below 10.4.4 expose Data Management SPL2 preview jobs and results to authenticated users who hold the preview_data_management_pipeline or edit_data_management_pipeline_job capability, because the Data Management REST API checks the capability but never verifies that the referenced preview job belongs to the requester. This lets such a user read or delete other users' preview jobs and their output by referencing an out-of-scope job ID. The exposure is limited: the vulnerable REST API only exists when the non-default Edge Processor feature is explicitly turned on, and the attacker must already have a valid account with one of the two specific capabilities. No public exploit code has been identified at time of analysis and there is no CISA KEV listing.
Improper access control in Splunk Enterprise (versions prior to 10.4.3, 10.2.7, 10.0.10, and 9.4.15) lets unauthenticated, network-positioned attackers reach functionality or data that should be restricted, exposing limited sensitive information with no integrity or availability impact (CVSS 3.1 base 5.3, AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N). The flaw is tracked as CWE-284 and was fixed by Splunk as part of a set of internally identified issues grouped by weakness class, each receiving its own CVE; no public exploit code has been identified at time of analysis, EPSS is a low 0.15% (3rd percentile), and CISA's SSVC assessment rates exploitation as none with partial technical impact. Because exploitation requires only network reachability of the affected interface and no credentials or user interaction, the practical exposure is driven mainly by whether a Splunk web/management interface is exposed beyond a trusted network segment.
Improper write restrictions in the App Key Value Store (KV Store) collections used by Splunk Secure Gateway let any authenticated Splunk user who does not hold the 'admin' or 'sc_admin' role modify alert and mobile-device recipient records, which downstream alerting and subscription workflows then consume. The flaw affects Splunk Enterprise below 10.4.3, 10.2.7, 10.0.10, and 9.4.15, and Splunk Secure Gateway below 3.10.11, 3.9.25, and 3.8.72, with an assessed CVSS of 6.3 (CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:L/A:L, CWE-732). No public exploit code has been identified at time of analysis and there is no KEV confirmation of active exploitation; risk is concentrated in deployments that actually run Secure Gateway, and impact is bounded to the integrity and confidentiality of Secure Gateway alert/subscription data rather than arbitrary Splunk data or host-level access.
Authenticated Splunk Enterprise users whose role holds the run_collect capability can bypass their role's configured index-access restrictions and write events into internal indexes they are not permitted to modify, because Splunk does not normalize whitespace in an index name before enforcing per-role index access. The flaw affects Splunk Enterprise releases below 10.4.3, 10.2.7, 10.0.10, and 9.4.15, and carries a CVSS 3.1 score of 4.3 (AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:L/A:N) - an integrity-only, low-severity impact with no disclosure of data and no service disruption; no public exploit identified at time of analysis.
An authenticated user with the edit_spl2_module_permissions capability in Splunk Enterprise 10.0.x before 10.0.10, 10.2.x before 10.2.7, and 10.4.x before 10.4.3 can bypass an app-read authorization check via the REST management API to retrieve SPL2 module permission grants for apps they are not permitted to view. This low-severity authorization flaw (CVSS 4.3, CWE-639) results only in limited disclosure of permission-grant metadata, with no write or availability impact, and no public exploit has been identified at time of analysis. Splunk Enterprise 9.4.x is not affected.
Splunk Enterprise below 10.4.3, 10.2.7, 10.0.10, and 9.4.15 fails to reject native usernames that end with a trailing period, allowing an authenticated user who holds a role with the edit_user capability to create such an account. Because the trailing period is stripped or normalized when deriving the per-user directory path, two distinct native usernames can resolve to the same per-user configuration data, so user-management operations may act on the wrong account or fail outright. The practical exposure is bounded: exploitation requires a high-privilege administrative capability (edit_user) on native Splunk authentication, and the outcome is configuration-data collision and misdirected administrative actions rather than code execution or bulk data theft. No public exploit code has been identified at time of analysis, and the issue is not listed in CISA KEV; vendor-released fixes are available. This is a low-priority, low-real-risk issue despite affecting a widely deployed enterprise product.
Low-privileged Splunk Enterprise users can retrieve the original source code of the Discover Splunk Observability Cloud app because production JavaScript bundles shipped with the app retain embedded source maps. The issue affects Splunk Enterprise below 10.4.3, below 10.2.7, and below 10.0.10 (10.0.x, 10.2.x, and 10.4.x branches); the 9.4.x line is explicitly not affected. Exploitation requires an authenticated account that does not hold the 'admin' or 'power' roles plus access to Splunk Web and the presence of the affected app, and the resulting disclosure is confined to the app's own source code with no integrity or availability impact; no public exploit has been identified at time of analysis, and vendor fixes are available.
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.
Server-side request forgery in Splunk Enterprise (below 10.4.3, 10.2.7, and 10.0.10) lets an authenticated user who holds a role with the read_o11y_content capability redirect an outbound request made by the Splunk App for Splunk Observability Cloud to an attacker-controlled host, thereby disclosing the configured Observability Cloud API token. The flaw exists because the app does not fully validate the destination of outbound requests; the request is triggered through the REST API, requires no user interaction, and is rated CVSS 6.5 (CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N), indicating a high-confidentiality but no integrity or availability impact. Exploitation is gated by a non-default capability, by the presence of the Observability Cloud app, and by an environment where an API token is configured; Splunk Enterprise 9.4.x is explicitly unaffected. No public exploit code and no confirmed active exploitation were identified at time of analysis, and a vendor patch is available.
Authenticated Splunk Enterprise users whose roles carry the run_collect capability can inject attacker-controlled content into system-level messages on the affected instance because the collect Search Processing Language (SPL) command fails to validate the index name before processing it. The flaw affects Splunk Enterprise 10.4 before 10.4.3, 10.2 before 10.2.7, 10.0 before 10.0.10, and 9.4 before 9.4.15, and is limited to a low integrity impact (CVSS 4.3, CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:L/A:N) with no confidentiality or availability loss and no user interaction required. Exploitation requires valid credentials plus a role granting run_collect - a non-default prerequisite that standard or restricted roles lack - and no public exploit has been identified at time of analysis; vendor patches are available, and this is a low-priority issue despite being network-reachable.
Splunk Secure Gateway (an app bundled with Splunk Enterprise) fails to verify that a requesting user is authorized to ask for a payload signature, so any authenticated Splunk user who does not hold the 'admin' or 'power' roles can coerce the gateway into signing attacker-controlled content. Affected builds are Splunk Enterprise versions below 10.4.3, 10.2.7, 10.0.10, and 9.4.15, together with Splunk Secure Gateway versions below 3.10.11, 3.9.25, and 3.8.72, as catalogued under CPE cpe:2.3:a:splunk:splunk_secure_gateway and cpe:2.3:a:splunk:splunk_enterprise. The impact is integrity-only (CVSS 4.3, AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:L/A:N): no confidentiality or availability effect, authenticated access and network reachability to the gateway are required, and there is no public exploit identified at time of analysis. Exploitation is confirmed as not appearing in CISA KEV, so the practical risk is confined to deployments where platform-signed payloads are subsequently trusted by downstream consumers.
Denial of service in Splunk Enterprise 10.x allows an authenticated user with only low-privileged roles to degrade or take down a REST API endpoint exposed by the Discover Splunk Observability Cloud app, because the app validates input with an inefficient regular expression that can be driven into excessive CPU consumption. Affected branches are 10.4.x below 10.4.3, 10.2.x below 10.2.7, and 10.0.x below 10.0.10; Splunk Enterprise 9.4.x is explicitly not affected, and the exposure only exists where the Observability Cloud preview app and its endpoint are present and reachable. Impact is confined to availability (no data disclosure or modification), no public exploit code has been identified at time of analysis, and the vendor has released fixes in 10.4.3, 10.2.7, and 10.0.10.
SQL injection in the SPL2 module filtering feature of Splunk Enterprise (10.4.x below 10.4.3) lets an authenticated user who holds a role with the list_spl2_modules capability read data exposed by the affected REST API, including private SPL2 module definitions owned by other users. The flaw is rooted in unparameterized user input being passed into database queries that back SPL2 module filtering, so a crafted filter value escapes the caller's intended module visibility scope; the impact is confidentiality-only with no write or availability effect, and the CVSS 3.1 vector (6.5, AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N) confirms the network-reachable but authenticated and low-privilege nature of the attack. No public exploit code has been identified at time of analysis and there is no CISA KEV listing, but a vendor patch is available in Splunk Enterprise 10.4.3, and Splunk Enterprise 10.2.x, 10.0.x, and 9.4.x are explicitly not affected.
An authenticated Splunk Enterprise user without the 'admin' or 'power' roles can read substantially all search job information belonging to other users - including raw search query text, job metadata, result sets, and preview results - by supplying a user-controlled job identifier to a REST API endpoint that fails to validate job ownership. The flaw affects Splunk Enterprise versions below 10.4.3, 10.2.7, 10.0.10, and 9.4.15, and carries a CVSS 3.1 base score of 6.5 (AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N), meaning the confidentiality impact is high but integrity and availability are untouched. No public exploit code has been identified at time of analysis and there is no confirmed active exploitation (not in CISA KEV); vendor patches are available, which reduces exposure for organizations that can upgrade promptly, though the requirement for valid low-privilege credentials limits risk to multi-user and shared-search deployments.
Authenticated log injection in Splunk Enterprise allows a user whose role carries the read_o11y_content capability to forge entries in the app log through the REST API, but only on deployments where the Splunk App for Splunk O11y Cloud is present and enabled. The root cause is CWE-117 - the app writes user-supplied SignalFlow content into the app log without neutralizing it - producing a low-impact integrity-only result (CVSS 4.3, AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:L/A:N) with no confidentiality or availability effect, and no public exploit identified at time of analysis. Only Splunk Enterprise releases below 10.4.3, 10.2.7 and 10.0.10 are affected; 9.4.x is explicitly not affected.
Missing authorization checks on multiple Splunk Secure Gateway REST API endpoints allow any authenticated Splunk user who does not hold the 'admin' or 'power' roles to reach privileged Secure Gateway functionality and make the gateway sign attacker-controlled payloads. The issue affects Splunk Enterprise versions below 10.4.3, 10.2.7, 10.0.10 and 9.4.15, as well as standalone Splunk Secure Gateway versions below 3.10.11, 3.9.25 and 3.8.72, and it requires a valid low-privilege Splunk account plus network reachability to the Secure Gateway REST API (CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:H/A:N per independent assessment; NVD publishes 6.5 with C:H/I:N). There is no public exploit identified at time of analysis and no confirmed active exploitation (CISA KEV), but a vendor patch is available and the integrity impact of forged signatures makes timely upgrade worthwhile.
Improper authorization in Splunk Enterprise (CWE-863) allows an authenticated user who does not hold the 'admin' or 'power' role to create or edit scripted lookup definitions through the raw transforms configuration write paths, which save those settings without applying the external lookup capability check that the standard lookup management UI enforces. Deployments running versions below 10.4.2, 10.2.6, 10.0.10, or 9.4.15 are affected, and exploitation requires a valid low-privilege account plus network access to the Splunk management/REST interface. The assessed CVSS 3.1 base score is 4.3 (AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:L/A:N), a moderate integrity-only authorization flaw; no public exploit code has been identified at time of analysis and the issue is not listed in CISA KEV.
Arbitrary file deletion on Splunk cluster managers is possible for any authenticated, low-privileged user - no admin or power role required - by submitting a crafted knowledge bundle delta containing path traversal sequences. Affected versions span four active release branches: 9.4.x before 9.4.14, 10.0.x before 10.0.9, 10.2.x before 10.2.6, and 10.4.x before 10.4.2. An attacker exploiting this flaw can delete files accessible to the Splunk process outside the intended staging directory, degrading system integrity or triggering service disruption on the cluster manager node. No public exploit code or CISA KEV listing has been identified at time of analysis.
SPL injection in Splunk Enterprise below versions 10.2.6, 10.0.9, and 9.4.14 enables an unauthenticated attacker to execute arbitrary Search Processing Language commands under the privileges of any authenticated Splunk user by luring that user into clicking a specially crafted Splunk Web URL. The root cause is unsanitized substitution of URL-supplied form token values directly into SPL searches, effectively turning the victim's browser session into a proxy for the attacker's queries. No public exploit code or CISA KEV listing has been identified at time of analysis, but the high confidentiality impact (C:H) makes this a meaningful data-exfiltration vector in targeted phishing scenarios against Splunk-heavy SOC or analytics environments.
Search Head Cluster member control endpoints in Splunk Enterprise fail to enforce HTTP method-based authorization, allowing a user holding the high-privilege `list_search_head_clustering` capability to send read-typed HTTP requests that alter cluster state and cause a denial of service. Four release branches are affected - 9.4.x, 10.0.x, 10.2.x, and 10.4.x - with fixed versions available from Splunk (SVD-2026-0801). No public exploit code or CISA KEV active-exploitation listing has been identified at time of analysis; exploitation is constrained to authenticated insiders or post-compromise attackers holding a high-privilege Splunk role.
Server-Side Request Forgery in Splunk Enterprise and Splunk Secure Gateway allows low-privileged authenticated users to manipulate internal Splunk services via crafted report notification paths. Affected versions span Splunk Enterprise below 10.4.2, 10.2.6, 10.0.9, and 9.4.14, and Splunk Secure Gateway below 3.10.9, 3.9.23, and 3.8.70. An attacker holding any valid Splunk account - excluding admin and power roles - can leverage the unvalidated path handling in Secure Gateway to issue system-authenticated internal requests, potentially disrupting Search Head Cluster state or causing denial of service. No public exploit code exists and this vulnerability is not listed in the CISA KEV catalog at time of analysis.
Stored cross-site scripting in Splunk Enterprise allows a 'power' role user to embed malicious JavaScript within dashboard sparkline format options, which then executes in the browser of any user who views that dashboard. If the victim holds the 'admin' Splunk role, the attacker effectively gains access to all data accessible through Splunk Web and can perform actions at admin-level permissions. Exploitation requires social engineering - the victim must be tricked into navigating to the malicious dashboard - and no public exploit code has been identified at time of analysis. Affected versions span four active release branches below 10.4.2, 10.2.6, 10.0.9, and 9.4.14.
Remote code execution in Splunk Enterprise 10.4.x allows a high-privilege user with search head cluster (SHC) management rights to write files to arbitrary locations accessible by the Splunk service account via the SHC member bundle REST API. The API fails to enforce authorization boundaries and does not validate bundle paths before accepting content, enabling path-traversal-style writes that can deliver and trigger malicious payloads. No public exploit code or active exploitation (CISA KEV) has been identified at time of analysis, but the RCE primitive makes this a meaningful risk in environments running Splunk 10.4 or 10.4.1 where high-privilege insider or compromised-account scenarios are plausible.
SQL injection in Splunk Enterprise's Data Orchestration jobs endpoint allows any authenticated low-privilege user - explicitly excluding the need for 'admin' or 'power' roles - to execute arbitrary SQL against the underlying Data Orchestration database, exposing all job records across all users and stored connection credentials. Affected version branches are 10.4.x below 10.4.2, 10.2.x below 10.2.6, 10.0.x below 10.0.9, and 9.4.x below 9.4.14. Reported by Cisco; no KEV listing or public exploit code identified at time of analysis, though the credential exposure component significantly elevates real-world impact beyond the moderate 6.5 CVSS score suggests.
Splunk Enterprise contains a stored SPL injection flaw in the Table Editor that allows a lower-privileged 'power' role user to plant risky Search Processing Language commands inside a shared dataset, which then execute silently under an 'admin' user's elevated permissions when that admin opens the dataset's Initial Data step. Affected versions span four release lines: below 10.4.2, 10.2.6, 10.0.9, and 9.4.14. A successful attack exposes all data accessible to the admin and allows modification of Splunk lookup files. No public exploit has been identified at time of analysis, and CISA KEV does not list this vulnerability as actively exploited.
Splunk Enterprise's Table Editor dataset feature permits a 'power' role user to inject attacker-controlled Search Processing Language (SPL) into a shared dataset, which silently executes with admin-level permissions when an administrator opens the dataset. Affected deployments span four version branches: 9.4 prior to 9.4.14, 10.0 prior to 10.0.9, 10.2 prior to 10.2.6, and 10.4 prior to 10.4.2. Because the Table Editor omits SPL safeguards for risky commands during the initial data preparation phase (CWE-863), a successfully phished admin can unwittingly expose all search-head-accessible data and allow limited data modification. No public exploit is identified at time of analysis, and the vulnerability does not appear in CISA's KEV catalog.
Unauthenticated token-signing key reload in Splunk Enterprise 10.4.x (below 10.4.2) exposes a REST API endpoint that lacks the required `change_authentication` capability check, permitting any network-reachable caller to force a key reload cycle without credentials. The flaw is classified under CWE-862 (Missing Authorization) and was reported by Cisco; a vendor patch is available at 10.4.2. No active exploitation has been confirmed and no public exploit code has been identified at time of analysis, though the low-complexity, unauthenticated network vector makes opportunistic probing straightforward once the endpoint is known.
SPL command injection through the geostats command in Splunk Enterprise allows an authenticated low-privileged attacker to execute arbitrary Search Processing Language commands under the security context of a second, higher-privileged victim user. Affected release branches include 10.4.x below 10.4.2, 10.2.x below 10.2.6, 10.0.x below 10.0.9, and 9.4.x below 9.4.14. Exploitation requires phishing an authenticated target into initiating the attacker-controlled search in Splunk Web; no public exploit has been identified at time of analysis and the vulnerability is not listed in the CISA KEV catalog.
Path traversal in Splunk Enterprise exposes JavaScript files outside the Splunk Web static directory to unauthenticated remote attackers across four active release branches. Splunk Web fails to enforce boundaries on static file requests, allowing directory traversal reads without any credentials. No public exploit code has been identified at time of analysis and this vulnerability is not listed in the CISA KEV catalog, but the trivially low attack complexity (AC:L, PR:N, UI:N) means exploitation requires no special tooling.
Dashboard Studio workflow actions in Splunk Enterprise can be weaponized by a 'power'-role user to store attacker-controlled SPL that executes under a victim's permission context when triggered via Event Actions. Affected versions span all major branches: 9.4 below 9.4.14, 10.0 below 10.0.9, 10.2 below 10.2.6, and 10.4 below 10.4.2. No public exploit code or CISA KEV listing exists at time of analysis, but successful exploitation enables unauthorized read and write access to data within the victim's Splunk permission scope.
Reflected SPL injection in Splunk Enterprise's Monitoring Console allows an unauthenticated attacker to execute attacker-controlled Search Processing Language queries under the permissions of a targeted Splunk administrator. The attacker must phish an admin-role user into opening a specially crafted link (CVSS UI:R/AC:H), making opportunistic mass exploitation unlikely, but a successful attack can expose all data indexed and accessible to that admin or corrupt lookup tables. Vendor-released patches are available for all affected branches; no public exploit code and no CISA KEV listing have been identified at time of analysis.
Improper neutralization weaknesses in Splunk Enterprise allow a network-positioned attacker holding a valid low-privilege account to achieve high confidentiality, integrity, and availability impact, with a scope change (S:C) indicating the effect can extend beyond the initially compromised component. Affected branches are Splunk Enterprise 9.4 before 9.4.16, 10.0 before 10.0.11, 10.2 before 10.2.8, and 10.4 before 10.4.4; CVSS 3.1 is 9.9 (AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H), so authentication is required but no user interaction is, and only the listed versions are in scope. Vendor fixes are available and the issue is prioritized act_now, but no public exploit code and no CISA KEV entry were identified at time of analysis; the two supplied references are one Splunk advisory plus an NVD detail page, so the corroborating signal quality is thin relative to the score.
Signals conflict and must be weighed carefully: Splunk Enterprise versions before 9.4.16, 10.0.11, 10.2.8, and 10.4.4 contain internally discovered protection-mechanism failures tracked as CVE-2026-76301 (CWE-693), rated CVSS 9.8 with a vector for unauthenticated network attackers and high confidentiality, integrity, and availability impact. The specific feature, protocol, configuration, trigger, and per-vulnerability impact are not disclosed in the available sources, and no public exploit was identified at time of analysis; EPSS is low at 0.17% (6th percentile). A vendor patch is available, and the vuln.today decision is act_now.
Splunk Enterprise releases 10.2 before 10.2.8, 10.0 before 10.0.11, 9.4 before 9.4.16 and 10.4 before 10.4.4 carry multiple internally discovered resource-lifetime flaws (CWE-664) that a remote attacker holding low-privileged credentials can use to gain high confidentiality, integrity and availability impact, with low attack complexity and no user interaction (CVSS 3.1 base 8.8, PR:L). Cisco/Splunk shipped the fixes in a consolidated hardening release rather than a single-feature advisory, so the specific triggering component is not described in the available sources; the only confirmed limiting factor is the need for valid low-privileged access. There is no CISA KEV entry and no confirmed working exploit code, and EPSS is low at 0.17% (6th percentile), though the vendor's this-week prioritisation and the breadth of the hardening release justify prompt upgrading.
Improper access control in Splunk Enterprise 9.4, 10.0, 10.2, and 10.4 allows a low-privileged authenticated user to cross a security boundary and achieve high confidentiality, integrity, and availability impact, making the release a 9.9 severity fix. The flaw was found during Cisco's internal hardening review rather than through external reporting, and the affected ranges are 9.4 before 9.4.16, 10.0 before 10.0.11, 10.2 before 10.2.8, and 10.4 before 10.4.4. No public exploit code has been identified and there is no CISA KEV entry, but vendor patch availability combined with an act_now priority label places upgraded discipline on anyone running an unpatched instance; the trigger is not described in the available sources.
Authenticated low-privileged Splunk Enterprise users can escalate to arbitrary OS command execution on search head cluster members by reconstructing the PostgreSQL sidecar superuser password. The password is deterministically derived from the search head cluster identifier, which surfaces in search job logs readable by users who do not hold the 'admin' or 'power' roles. Deployments below 10.4.4 and below 10.2.8 are affected where a search head cluster runs the PostgreSQL sidecar service; no public exploit code has been identified at time of analysis, but the flaw carries a CVSS score of 8.8 (AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H) and warrants prompt patching in SHC environments.
Remote code execution in Splunk Enterprise is possible for authenticated users whose roles include the edit_manager_xml capability; by opening a crafted Manager XML configuration in Splunk Web, they can execute arbitrary operating-system commands with the privileges of the account running Splunk Enterprise. The flaw affects versions below 10.4.3, 10.2.8, 10.0.11, and 9.4.16. No public exploit was identified at time of analysis, and the high-privilege prerequisite confines meaningful exposure to environments where edit_manager_xml is assigned broadly rather than tightly restricted to trusted administrators.
Authenticated Splunk Enterprise users whose roles include the schedule_search capability can use the scheduled search workflow to run risky SPL commands that the platform would normally block, resulting in disclosure or alteration of Splunk data or disruption of Splunk availability. The issue affects Splunk Enterprise versions below 10.4.4, 10.2.8, 10.0.11, and 9.4.16, and is fixed in those releases. The assessed vector requires low privileges (PR:L) and no user interaction, with high confidentiality, integrity, and availability impact; no public exploit identified at time of analysis.
Unauthenticated denial of service in Splunk Enterprise deployments below 10.4.4, 10.2.8, and 10.0.11 is reachable through the Edge Processor package download endpoint in the Splunk Pipeline Builders app. Repeated unauthenticated requests force the Splunk daemon to read and base64-encode the complete package in memory for each request, exhausting system resources and potentially making the service stop responding (CVSS 7.5, CWE-400). Exposure is limited to instances running Edge Processor/Pipeline Builders, and no public exploit identified at time of analysis.
Splunk Enterprise deployments running Splunk Web in versions below 10.4.4, 10.2.8, 10.0.11, and 9.4.16 can be taken offline by a single unauthenticated request to the Splunk Web JavaScript logger endpoint, which parses request headers without any limit and can be driven into an unresponsive state. Recovery requires a full restart of Splunk Enterprise, making this an easy-to-repeat availability attack against any instance whose Splunk Web port is reachable by the attacker. The assessed vector (AV:N/AC:L/PR:N/UI:N, availability-only) is consistent with a low-complexity denial of service; no public exploit code or confirmed active exploitation was identified at time of analysis, and the risk is bounded to service availability with no implied data loss or compromise.
Splunk Enterprise installations at versions below 9.4.15, 10.0.10, 10.2.7, and 10.4.3 are affected by a coding-standard defect that the vendor rates at CVSS 3.1 base 9.8 (AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H), meaning a remote, unauthenticated network attacker could in principle achieve full loss of confidentiality, integrity, and availability. The issue is one of several internally identified findings that Splunk grouped under CWE-710 (Improper Adherence to Coding Standards) and documents in advisory SVD-2026-1002; because the advisory groups multiple defects by weakness class, it does not enumerate the specific component, feature, or configuration prerequisite involved, so the exact attack path cannot be confirmed from available data. Practical risk is presently tempered: EPSS is only 0.14 percent (3rd percentile) and there is no public exploit identified at time of analysis, with no CISA KEV listing indicating confirmed active exploitation; the dominant exposure factor is network reachability to the Splunk web interface or management port, which in many enterprise deployments is restricted to internal networks rather than internet-exposed.
Improper neutralization (injection-class weakness, CWE-707) in Splunk Enterprise lets an attacker submit crafted input through a network-reachable Splunk interface and achieve high impact across confidentiality, integrity, and availability - per our independent assessment, exploitation requires low-privilege authentication (CVSS:3.1/AV:N/AC:L/PR:L/UI:N), even though the upstream NVD-style vector claims PR:N/unauthenticated. Affected are Splunk Enterprise 10.4 before 10.4.3, 10.2 before 10.2.7, 10.0 before 10.0.10, and 9.4 before 9.4.15; the vendor grouped multiple internally identified findings by CWE and assigned this CVE to the neutralization group, so the advisory names no single endpoint or feature. No public exploit code has been identified at time of analysis, EPSS is only 0.15% (4th percentile), and the vulnerability is not listed as confirmed actively exploited (CISA KEV), so urgency should be driven by the critical severity and the accessibility of the affected interface rather than by observed exploitation.
Authenticated information disclosure in Splunk Enterprise allows a low-privileged account to bypass an intended security control and access data it should not be able to reach, affecting versions below 10.4.3, 10.2.7, 10.0.10, and 9.4.15. Rated CVSS 7.6 (AV:N/AC:L/PR:L/UI:N, with high confidentiality impact but only low integrity and availability impact), the issue is classified as CWE-693, Protection Mechanism Failure, and requires only a valid Splunk account with network reachability to the instance - no user interaction is needed, but a fully unauthenticated outsider cannot exploit it. No public exploit code and no confirmed active exploitation have been identified at time of analysis, and the vendor has released fixed builds for all four affected release trains for this internally discovered flaw.
Authenticated low-privilege users with network access to the Splunk Enterprise management/web interface can abuse improper resource lifetime handling to achieve high confidentiality, integrity, and availability impact on deployments running versions below 9.4.15, 10.0.10, 10.2.7, or 10.4.3. The flaw is rated CVSS 8.8 (AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H) and is one of a group of internally discovered issues covered by Splunk advisory SVD-2026-1002, where CVEs are assigned per CWE group, so the specific vulnerable subsystem is not individually named. Real-world likelihood currently appears limited: EPSS is 0.15% (4th percentile), there is no CISA KEV listing and no public exploit identified at time of analysis, and the primary gating factor is that an attacker must already hold valid Splunk credentials or a session.
Unauthenticated remote command execution in Splunk Enterprise search head cluster members allows any network-reachable attacker to run operating-system commands as the Splunk service account. The flaw (CWE-306) is that the Patroni REST API exposed on a search head cluster member performs critical configuration operations without requiring authentication, so an attacker who can reach that interface can invoke it directly - no credentials needed. Only deployments running search head clustering on Splunk Enterprise versions below 10.4.3 or below 10.2.7 are exposed; 10.0.x and 9.4.x are explicitly unaffected. CVSS 3.1 base 9.8 (AV:N/AC:L/PR:N/UI:N/C:H/I:H/A:H) reflects a maximum-severity, low-complexity path with full confidentiality, integrity and availability impact, and no public exploit code or confirmed active exploitation has been identified at time of analysis, so exposure is driven mainly by whether the Patroni REST API port is reachable from untrusted networks.
Local privilege escalation in Splunk Enterprise on Linux (versions below 10.4.3, 10.2.7, 10.0.10, and 9.4.15) allows an attacker who can already run commands as the OS account running Splunk Enterprise to inject operating-system commands into installation content that a subsequent root-privileged Linux package upgrade will execute as root. The flaw is conditional: the attacker must modify the installation and then a privileged package upgrade must occur, so there is no at-will escalation. No public exploit or confirmed active exploitation was identified at time of analysis.
Unauthenticated remote disclosure of Edge Processor pipeline configurations in Splunk Enterprise 10.4.x exposes potentially sensitive data-processing logic to any network-accessible attacker. The REST API endpoint serving Edge Processor configuration lacks authentication controls (CWE-306), meaning any unauthenticated actor can retrieve pipeline details when the Edge Processor feature is enabled. No public exploit code has been identified at time of analysis, and the flaw is restricted to the 10.4.x branch - prior versions are unaffected.
Search Head Clustering bundle replication in Splunk Enterprise fails to validate bundle filenames or neutralize NUL bytes before constructing file system paths on non-captain cluster members, allowing any authenticated low-privileged user to delete or temporarily overwrite files accessible to the Splunk service account via a crafted REST API request. Affected are Splunk Enterprise versions below 10.4.2, 10.2.6, 10.0.9, and 9.4.14 running in SHC deployments - standalone instances are not in scope. No public exploit code has been identified at time of analysis and this CVE is not listed in CISA KEV; however, vendor patch is available via advisory SVD-2026-0801 and the low privilege barrier makes this a credible insider or stolen-credential threat in SOC environments.
Privilege escalation in Splunk Enterprise allows any authenticated low-privileged user to create or modify scripted lookups through improperly guarded generic transforms configuration endpoints, gaining code execution under the Splunk service account's operating system permissions. Affected versions span four release branches: 9.4.x below 9.4.14, 10.0.x below 10.0.9, 10.2.x below 10.2.6, and 10.4.x below 10.4.2. An attacker holding any valid Splunk account - without requiring the 'admin' or 'power' roles - can abuse this to access all Splunk-indexed data and compromise system integrity and availability. No public exploit or CISA KEV listing has been identified at time of analysis.
Splunk Secure Gateway's failure to validate decoded report notification identifiers enables any authenticated low-privileged user to hijack system-level REST API sessions in Splunk Enterprise, achieving full configuration control and credential theft without requiring admin or power role. Affected versions span multiple Splunk Enterprise branches (9.4.x, 10.0.x, 10.2.x, 10.4.x) and Splunk Secure Gateway branches (3.8.x, 3.9.x, 3.10.x). No public exploit code or CISA KEV listing has been identified at time of analysis, but the low-complexity, low-privilege attack path and high-impact outcome (C:H/I:H/A:H) make this a realistic internal threat in any multi-tenant or shared Splunk deployment.
Privilege escalation in Splunk Enterprise allows any user holding the schedule_search capability to execute arbitrary SPL commands with system-level privileges on the search head by configuring PDF attachments in the email alert action workflow. The flaw exists because the search scheduler substitutes a system-level authentication context for the alert owner's context during PDF rendering, effectively granting the authenticated user full system access. Affected are all Splunk Enterprise installations across the 9.4, 10.0, 10.2, and 10.4 release branches below the patched versions; no public exploit or CISA KEV listing is identified at time of analysis.
Path traversal in Splunk Enterprise allows low-privileged authenticated users to write dispatch metadata to arbitrary locations on the host filesystem by supplying a crafted search identifier to a REST API endpoint. Affected branches span versions below 10.4.2, 10.2.6, 10.0.9, and 9.4.14, covering all currently maintained Splunk Enterprise release lines. No public exploit has been identified at time of analysis and the vulnerability is absent from CISA KEV, but the low complexity, network accessibility, and high integrity impact create meaningful risk on unpatched instances, particularly given the potential for filesystem write primitives to be chained into privilege escalation.
Authentication bypass in Splunk Enterprise across multiple supported version branches allows an attacker who has obtained a trusted distributed search private key to forge administrative session tokens entirely over the network. Affected versions span 9.4.x below 9.4.14, 10.0.x below 10.0.9, 10.2.x below 10.2.6, and 10.4.x below 10.4.2. Once a forged token is accepted, the attacker gains full confidentiality, integrity, and availability impact equivalent to an administrator - including access to all indexed data and the ability to disrupt search services. No public exploit or CISA KEV listing exists at time of analysis; this was reported by Cisco, suggesting coordinated disclosure from security research.
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.
Authenticated low-privilege code injection in Splunk Enterprise allows OS command execution on the host system as the Splunk process account. Affected versions span four active release lines (9.4.x, 10.0.x, 10.2.x, 10.4.x), and the root cause is a missing capability check: Splunk Web accepts Splunk Web Manager XML configuration writes without enforcing the edit_manager_xml permission, meaning any authenticated user can plant attacker-controlled content that executes when the Manager page is rendered. No active exploitation is confirmed in CISA KEV, and no public exploit code has been identified at time of analysis, but the CVSS score of 8.8 (High) and straightforward exploitation path make this a high-priority patching target for Splunk deployments.
Stored cross-site scripting in Splunk Enterprise's Dashboard Studio allows a user holding the 'power' role to persist a crafted workflow action URL that, when triggered by a separate authenticated victim, executes attacker-controlled JavaScript in the victim's browser session. All four actively maintained branches are affected: 10.4.x below 10.4.2, 10.2.x below 10.2.6, 10.0.x below 10.0.9, and 9.4.x below 9.4.14. No public exploit has been identified at time of analysis, and exploitation is constrained by a required internal 'power' role and mandatory victim social engineering, meaningfully limiting the realistic attacker population despite the high impact ratings.
SPL injection via Analytics Workspace in Splunk Enterprise allows an unauthenticated attacker to execute arbitrary Search Processing Language queries under the permissions of a phished authenticated user. Affected across four release trains - 9.4 below 9.4.14, 10.0 below 10.0.9, 10.2 below 10.2.6, and 10.4 below 10.4.2 - the flaw stems from insufficient input validation when Analytics Workspace constructs searches from URL-embedded data. No public exploit code has been identified at time of analysis, and the vulnerability is not listed in the CISA KEV catalog, though exploitation impact scales directly with the victim user's Splunk role and data access.
SPL injection in Splunk Enterprise exposes all indexed data and compromises search integrity for any low-privileged authenticated user. Specifically, users without the 'admin' or 'power' role can inject Search Processing Language commands into saved-search dispatch requests by supplying malicious time values that Splunk Enterprise fails to validate. Patch versions have been released across all supported branches; no public exploit code or CISA KEV listing has been identified at time of analysis.
Reflected SPL injection in Splunk Enterprise's Monitoring Console allows an unauthenticated attacker to execute attacker-controlled Search Processing Language commands under the permissions of a phished authenticated victim. Affected versions span four active release trains: 9.4.x below 9.4.14, 10.0.x below 10.0.9, 10.2.x below 10.2.6, and 10.4.x below 10.4.2. No public exploit or CISA KEV listing exists at time of analysis, though successful exploitation grants full read and write access to all data and actions permitted by the victim's Splunk role.
Stored cross-site scripting in Splunk Enterprise allows a 'power' role user to persist a malicious ui-tour knowledge object that executes arbitrary JavaScript in the browser of any authenticated user who visits an affected Splunk Web page. Affected are all Splunk Enterprise deployments running versions below 10.4.2, 10.2.6, 10.0.9, or 9.4.14, a broad multi-branch footprint reported via Cisco and confirmed by Splunk advisory SVD-2026-0801. No public exploit code or CISA KEV listing has been identified at time of analysis, but the CVSS 7.3 rating and high confidentiality and integrity impact scores reflect meaningful lateral risk within an enterprise's Splunk deployment.
SPL injection in Splunk Enterprise's Job Details dashboard enables a low-privileged authenticated attacker to bypass Search Processing Language risky-command safeguards by embedding a malicious search identifier in a crafted dashboard URL and phishing an authenticated victim into opening it. The injected SPL executes under the victim's permissions, potentially exposing all data accessible to that user and compromising search integrity within those bounds. No active exploitation is confirmed and no public exploit code has been identified; a vendor patch is available across all four affected release trains per advisory SVD-2026-0801.
Dashboard Studio in Splunk Enterprise (below versions 9.4.14, 10.0.9, 10.2.6, and 10.4.2) allows a low-privileged 'user'-role account to inject attacker-controlled SPL queries that execute within the authenticated session of a different, potentially higher-privileged victim user. The root cause is Dashboard Studio's failure to consistently enforce app-visibility authorization boundaries before search query options reach the search dispatch layer - a CWE-862 Missing Authorization defect. No public exploit code or active exploitation has been confirmed; a vendor patch is available across all affected branches.
Unauthenticated SPL injection in Splunk Enterprise's nearby-event search feature allows remote attackers to execute arbitrary Search Processing Language queries without authorization across versions 9.4.x, 10.0.x, 10.2.x, and 10.4.x. The root cause is a two-pronged failure: Splunk Web does not consistently escape caller-supplied values when constructing SPL for nearby-event searches, and the embedded report access endpoint accepts those crafted requests without performing the expected authorization check. No public exploit code or active exploitation (CISA KEV) has been identified at time of analysis, but the unauthenticated network vector and wide enterprise deployment of Splunk make this a priority patch.
Remote code execution in Splunk Enterprise allows any low-privileged authenticated user to execute arbitrary code by exploiting a missing authorization check in the Federated Search dispatch flow. The vulnerability stems from the platform accepting caller-controlled bundle selection without verifying the fsh_manage capability, meaning any user with basic login access can escalate to full RCE. All four active version branches (9.4.x, 10.0.x, 10.2.x, 10.4.x) are affected below their respective patch thresholds; no public exploit or CISA KEV listing has been identified at time of analysis.
Path traversal in Splunk Enterprise's lookup configuration endpoint allows any authenticated low-privileged user - without admin or power roles - to move arbitrary files readable by the Splunk service account into a user-controlled lookup table on the search head. Affected versions span four active release trains: 10.4.x below 10.4.2, 10.2.x below 10.2.6, 10.0.x below 10.0.9, and 9.4.x below 9.4.14. With a CVSS score of 8.8 and no special configuration required beyond a standard Splunk account, successful exploitation yields full confidentiality, integrity, and availability impact; no public exploit has been identified at time of analysis and the vulnerability is not listed in CISA KEV.
Stored SPL injection in Splunk Enterprise allows an unauthenticated attacker who can reach the management port to register a crafted Deployment Server client identity containing malicious Search Processing Language code, which executes when an administrator opens the Add Data forwarder workflow. All four supported major branches are affected (9.4.x, 10.0.x, 10.2.x, 10.4.x), with vendor-confirmed fixes available. No public exploit has been identified at time of analysis, but successful exploitation yields full confidentiality, integrity, and availability impact on the Splunk platform instance.
Remote code execution in Splunk Enterprise allows any authenticated low-privileged user - one without the 'admin' or 'power' role - to inject and execute arbitrary code on the Splunk platform instance via the Splunk Web Manager Configuration REST API endpoint. The root cause is a missing permission check on the REST API path governing manager configuration writes, meaning Splunk evaluates attacker-supplied configuration values without verifying the caller holds the required role. Exploitation yields full confidentiality, integrity, and availability impact on the Splunk instance; no public exploit has been identified at time of analysis.
Remote code execution in Splunk Enterprise allows any authenticated low-privilege user - one who does not hold the 'admin' or 'power' role - to execute arbitrary code by submitting crafted XML content to the Splunk Web Manager Configuration endpoint. The vulnerability combines two weaknesses: server-side evaluation of manager XML expressions without sufficient input restrictions (CWE-94), and a missing capability check on the configuration route that should gate such access. No public exploit has been identified at time of analysis, but the low attack complexity and low privilege requirement make this a high-priority remediation target across Splunk Enterprise 9.4.x, 10.0.x, 10.2.x, and 10.4.x branches.
Remote code execution in Splunk Enterprise allows any authenticated low-privilege user (without admin or power roles) to upload a malicious knowledge bundle via the REST API and force distributed search to execute it across search peers, achieving full C/I/A compromise. The root cause is a missing authorization check - the REST API endpoint for knowledge bundle uploads does not enforce the required edit_dist_peer capability, and distributed search blindly honors caller-supplied bundle selections. No public exploit or CISA KEV listing has been identified at time of analysis, but the low authentication bar (any valid Splunk account suffices) and network-accessible attack surface make this a high-priority patching target in enterprise environments.
Session material exposure in Splunk Enterprise (versions below 10.4.1, 10.2.6, 10.0.9, and 9.4.14) allows an unauthenticated attacker who can view the HTML source of any page that embeds a Splunk report to harvest session credentials and reach the underlying search data with high confidentiality and integrity impact. The flaw stems from the dispatch archive download path failing to enforce the embedded-report authorization boundary, so archived search-job data carries sensitive session material. Rated CVSS 9.4 and reported by Cisco; no public exploit is identified at time of analysis and it is not listed in CISA KEV.
Improper access control in Splunk Enterprise (versions below 10.4.2, 10.2.6, 10.0.9, and 9.4.14) allows a party holding only an embedded report token to download the dispatch archive of an embedded report's search job, exposing session material that grants access to sensitive data and the ability to affect platform integrity. The embedded-report authorization flow fails to block dispatch-archive download requests before the archive begins streaming, so the check is effectively bypassed (CWE-284). No public exploit has been identified at time of analysis, but the 9.4 CVSS score and unauthenticated network vector make this a high-priority patch.
Improper access control in Splunk Enterprise (versions below 10.4.2, 10.2.6, 10.0.9, and 9.4.14) lets anyone holding an embedded report token download the underlying search job's dispatch archive over the REST API, recover session material, and impersonate the report owner. Because embedded reports are designed to be shared with unauthenticated viewers, an attacker can read all data the owner can access and, if the owner holds the admin role, perform administrative actions. No public exploit is identified at time of analysis, but the CVSS 9.4 rating and unauthenticated network vector make this high priority.
Unauthenticated information disclosure in Splunk Enterprise 10.4.x exposes Prometheus service metrics from the Edge Processor SPL2 Preview sidecar to any network-reachable client. The sidecar's Prometheus metrics endpoint lacks authentication, allowing retrieval of runtime and build metadata without credentials. No public exploit code has been identified at time of analysis, and the vulnerability does not affect Splunk Enterprise versions below 10.4.
Splunk Enterprise for Windows exposes a startup race condition on the management port that allows a low-privileged local user to intercept authentication tokens from Splunk child processes. By pre-binding the management port before the Splunk service initializes - exploiting the absence of exclusive address binding protections on Windows - an attacker captures session tokens that can be replayed to compromise all data and system integrity accessible to the Splunk service account. No public exploit code has been identified and EPSS is 0.12% (3rd percentile), indicating low current exploitation activity; however, the vulnerability is Windows-specific and patch is available from Splunk.
The Data Model Editor in Splunk Enterprise fails to apply SPL safeguards for risky commands when executing base searches for auto-extracted fields, allowing a low-privileged attacker (non-admin, non-power role) to craft a malicious request that executes arbitrary SPL commands under a victim's authenticated session via browser-based phishing. Affected branches span four active release lines - 9.4.x below 9.4.13, 10.0.x below 10.0.8, 10.2.x below 10.2.6, and 10.4.x below 10.4.1 - confirmed by vendor advisory SVD-2026-0801. No public exploit code or CISA KEV listing has been identified at time of analysis; vendor patches are available for all affected branches.
SPL injection via Dataset Explorer in Splunk Enterprise allows an unauthenticated attacker to cause an authenticated victim to execute arbitrary Search Processing Language pipelines under that victim's own privileges. Affected versions span five concurrent release branches - 10.4 below 10.4.2, 10.2 below 10.2.6, 10.0 below 10.0.9, 9.4 below 9.4.14, and 9.3 below 9.3.14 - giving this vulnerability broad reach across common enterprise deployments. No CISA KEV listing and no public exploit code have been identified at time of analysis, but the CVSS 8.8 score, wide deployment footprint, and straightforward phishing delivery mechanism make patching urgent.
Privilege escalation in Splunk Enterprise allows an authenticated user holding the schedule_search capability to execute arbitrary SPL commands at the highest system privilege level and read every credential stored in the credential store. Affected versions span four supported release lines - below 10.4.2, 10.2.6, 10.0.9, and 9.4.14 - meaning a wide swath of unpatched deployments across all current branches are exposed. No public exploit has been identified at time of analysis and no CISA KEV listing exists, but the credential store access potential makes this a high-priority patch for any deployment where the schedule_search capability is assigned to non-administrator users.
Missing authorization in the Splunk App for Splunk Observability Cloud exposes a stored Observability Cloud access token to any authenticated Splunk user lacking the admin or power role. Affected versions of Splunk Enterprise (below 10.4.2, 10.2.6, and 10.0.9) ship REST API endpoint handlers in the Observability Cloud integration app that fail to enforce the read_o11y_content capability before proxying requests - and the stored token - to Splunk Observability Cloud. Exploitation gives the low-privileged user full read access to all data visible to that token and limited write access to Observability Cloud content. No public exploit or KEV listing has been identified at time of analysis.
Cross-Site Request Forgery combined with SPL injection in Splunk Enterprise (below 10.4.1, 10.2.5, 10.0.8, 9.4.13) and Splunk Cloud Platform lets an attacker trick a logged-in user holding the list_deployment_server capability into unknowingly executing attacker-controlled Search Processing Language searches as the privileged splunk-system-user, exposing stored credentials and indexed data. The flaw stems from Deployment Server endpoints in Splunk Web accepting unvalidated GET requests without CSRF token checks and failing to neutralize caller input before it reaches an SPL search. No public exploit has been identified at time of analysis and it is not listed in CISA KEV.
Arbitrary file write in Splunk Enterprise (versions below 10.4.1, 10.2.5, 10.0.8, 9.4.13, 9.3.14) and Splunk Cloud Platform lets a privileged user with the edit_local_apps and install_apps capabilities abuse the app-installation workflow to write files outside the target app directory into $SPLUNK_HOME/etc/ and its subdirectories. The flaw is a path traversal (CWE-22) that can be leveraged to overwrite Splunk configuration and system files, yielding high confidentiality, integrity, and availability impact. No public exploit identified at time of analysis and it is not listed in CISA KEV.
Unauthenticated arbitrary file write in Splunk Enterprise (below 10.2.4 and 10.0.7) and Splunk Cloud Platform (below 10.4.2604.3 and 10.2.2510.14) allows remote attackers to create or truncate files on the host via an unauthenticated PostgreSQL sidecar service endpoint. The CVSS 9.8 vector (AV:N/AC:L/PR:N/UI:N) reflects trivial network exploitation, and no public exploit identified at time of analysis, though the missing-auth root cause and Splunk's high-value position in enterprise SOCs makes prompt patching warranted.
Server-side request forgery in Splunk Enterprise (below 10.2.4, 10.0.7, 9.4.12, 9.3.13) and Splunk Cloud Platform lets a low-privileged authenticated user coerce the Dashboard Studio PDF export feature into issuing HTTP requests to arbitrary internal destinations. The flaw stems from a flawed prefix-match on trusted domains plus uncritical redirect-following by the PDF export service. No public exploit identified at time of analysis, and the issue is not listed in CISA KEV.
Remote code execution in Splunk Enterprise, Splunk Cloud Platform, and the Splunk Secure Gateway app allows a low-privileged authenticated user (without 'admin' or 'power' roles) to execute arbitrary Python on the server by abusing unsafe jsonpickle deserialization of App Key Value Store (KV Store) data. CVSS is 8.8 (network, low complexity, low privileges) and the issue is currently rated as no public exploit identified at time of analysis. The flaw is reported by Cisco and disclosed via Splunk advisory SVD-2026-0601.
Remote code execution in Splunk Enterprise and Splunk Cloud Platform is achievable by low-privileged users - those without the admin or power role - by uploading a malicious file to the `$SPLUNK_HOME/var/run/splunk/apptemp` directory, exploiting insufficient isolation of temporary files (CWE-377). Affected versions span Splunk Enterprise below 10.2.1/10.0.5/9.4.10/9.3.11 and multiple Splunk Cloud Platform release trains. No public exploit code has been identified and CISA has not listed this in KEV; SSVC assigns Exploitation: none and Automatable: no, indicating low immediate threat despite total technical impact.
Cross-site request forgery in Splunk Enterprise allows an unauthenticated attacker to trick a user who holds the edit_federated_providers capability into disabling all configured federated search providers, temporarily preventing federated searches from retrieving remote data. The issue affects releases below 10.4.4, 10.2.8, 10.0.11, and 9.4.16, and exploitation requires the victim to be authenticated, privileged, and induced to click a crafted link; no public exploit code was identified at time of analysis.
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.
Information disclosure in Splunk Enterprise (below 10.4.4, 10.2.8, 10.0.11, and 9.4.16) and Splunk Secure Gateway (below 3.10.12, 3.9.26, and 3.8.73) allows an authenticated user who does not hold the admin or power roles to view dashboard and report listings beyond the requested filter scope. The flaw is a low-severity (CVSS 4.3) NoSQL-style filter injection in Secure Gateway that is limited to objects the user can already access, so it widens listing visibility rather than granting access to forbidden objects. No public exploit code or CISA KEV entry was identified at time of analysis, and exposure requires that Secure Gateway be in use.
Improper authorization in the Splunk Enterprise REST API allows an authenticated user without the 'admin' or 'power' roles to relocate field extractions and field transformations into apps they are not permitted to read, because the move operation never validates destination-app access. The issue affects deployments running versions below 10.4.4, 10.2.8, 10.0.11, and 9.4.16, and carries a CVSS score of 4.3 (AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:L/A:N), reflecting a limited integrity impact with no confidentiality or availability loss. No public exploit code has been identified at time of analysis and the issue is not listed in CISA KEV, so this is a low-to-moderate priority hardening item rather than an urgent exposure, though the required credential is a low-privilege one that many environments grant broadly.
Splunk Secure Gateway exposes mobile alert notification data belonging to other users to any authenticated low-privileged account that lacks the admin Splunk role or sc_admin Secure Gateway role. The flaw is missing user-level authorization on read requests to certain Secure Gateway App Key Value Store (KV Store) REST API collections, and it affects Splunk Enterprise releases below 10.4.4, 10.2.8, 10.0.11, and 9.4.16 plus Secure Gateway releases below 3.10.12, 3.9.26, and 3.8.73. No public exploit has been identified at time of analysis, and the vendor-assigned CVSS 3.1 score is 6.5 with a confidentiality-only impact.
Denial of service in Splunk Enterprise allows a low-privileged authenticated user to render the entire instance unavailable, requiring a manual restart to restore service. The flaw is a missing resource-consumption limit in the REST API endpoint for lookup table files, which fails to bound response field selections (CWE-770). Splunk Enterprise versions below 10.4.4, 10.2.8, 10.0.11, and 9.4.16 are affected; exploitation requires only a valid Splunk account (PR:L) that need not hold the admin or power roles, and no public exploit code or active exploitation has been identified at time of analysis. Impact is strictly availability - no data confidentiality or integrity loss - making this a genuine but moderate-priority issue that escalates in environments with broad API access.
Splunk Enterprise deployments below 10.4.4 expose Data Management SPL2 preview jobs and results to authenticated users who hold the preview_data_management_pipeline or edit_data_management_pipeline_job capability, because the Data Management REST API checks the capability but never verifies that the referenced preview job belongs to the requester. This lets such a user read or delete other users' preview jobs and their output by referencing an out-of-scope job ID. The exposure is limited: the vulnerable REST API only exists when the non-default Edge Processor feature is explicitly turned on, and the attacker must already have a valid account with one of the two specific capabilities. No public exploit code has been identified at time of analysis and there is no CISA KEV listing.
Improper access control in Splunk Enterprise (versions prior to 10.4.3, 10.2.7, 10.0.10, and 9.4.15) lets unauthenticated, network-positioned attackers reach functionality or data that should be restricted, exposing limited sensitive information with no integrity or availability impact (CVSS 3.1 base 5.3, AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N). The flaw is tracked as CWE-284 and was fixed by Splunk as part of a set of internally identified issues grouped by weakness class, each receiving its own CVE; no public exploit code has been identified at time of analysis, EPSS is a low 0.15% (3rd percentile), and CISA's SSVC assessment rates exploitation as none with partial technical impact. Because exploitation requires only network reachability of the affected interface and no credentials or user interaction, the practical exposure is driven mainly by whether a Splunk web/management interface is exposed beyond a trusted network segment.
Improper write restrictions in the App Key Value Store (KV Store) collections used by Splunk Secure Gateway let any authenticated Splunk user who does not hold the 'admin' or 'sc_admin' role modify alert and mobile-device recipient records, which downstream alerting and subscription workflows then consume. The flaw affects Splunk Enterprise below 10.4.3, 10.2.7, 10.0.10, and 9.4.15, and Splunk Secure Gateway below 3.10.11, 3.9.25, and 3.8.72, with an assessed CVSS of 6.3 (CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:L/A:L, CWE-732). No public exploit code has been identified at time of analysis and there is no KEV confirmation of active exploitation; risk is concentrated in deployments that actually run Secure Gateway, and impact is bounded to the integrity and confidentiality of Secure Gateway alert/subscription data rather than arbitrary Splunk data or host-level access.
Authenticated Splunk Enterprise users whose role holds the run_collect capability can bypass their role's configured index-access restrictions and write events into internal indexes they are not permitted to modify, because Splunk does not normalize whitespace in an index name before enforcing per-role index access. The flaw affects Splunk Enterprise releases below 10.4.3, 10.2.7, 10.0.10, and 9.4.15, and carries a CVSS 3.1 score of 4.3 (AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:L/A:N) - an integrity-only, low-severity impact with no disclosure of data and no service disruption; no public exploit identified at time of analysis.
An authenticated user with the edit_spl2_module_permissions capability in Splunk Enterprise 10.0.x before 10.0.10, 10.2.x before 10.2.7, and 10.4.x before 10.4.3 can bypass an app-read authorization check via the REST management API to retrieve SPL2 module permission grants for apps they are not permitted to view. This low-severity authorization flaw (CVSS 4.3, CWE-639) results only in limited disclosure of permission-grant metadata, with no write or availability impact, and no public exploit has been identified at time of analysis. Splunk Enterprise 9.4.x is not affected.
Splunk Enterprise below 10.4.3, 10.2.7, 10.0.10, and 9.4.15 fails to reject native usernames that end with a trailing period, allowing an authenticated user who holds a role with the edit_user capability to create such an account. Because the trailing period is stripped or normalized when deriving the per-user directory path, two distinct native usernames can resolve to the same per-user configuration data, so user-management operations may act on the wrong account or fail outright. The practical exposure is bounded: exploitation requires a high-privilege administrative capability (edit_user) on native Splunk authentication, and the outcome is configuration-data collision and misdirected administrative actions rather than code execution or bulk data theft. No public exploit code has been identified at time of analysis, and the issue is not listed in CISA KEV; vendor-released fixes are available. This is a low-priority, low-real-risk issue despite affecting a widely deployed enterprise product.
Low-privileged Splunk Enterprise users can retrieve the original source code of the Discover Splunk Observability Cloud app because production JavaScript bundles shipped with the app retain embedded source maps. The issue affects Splunk Enterprise below 10.4.3, below 10.2.7, and below 10.0.10 (10.0.x, 10.2.x, and 10.4.x branches); the 9.4.x line is explicitly not affected. Exploitation requires an authenticated account that does not hold the 'admin' or 'power' roles plus access to Splunk Web and the presence of the affected app, and the resulting disclosure is confined to the app's own source code with no integrity or availability impact; no public exploit has been identified at time of analysis, and vendor fixes are available.
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.
Server-side request forgery in Splunk Enterprise (below 10.4.3, 10.2.7, and 10.0.10) lets an authenticated user who holds a role with the read_o11y_content capability redirect an outbound request made by the Splunk App for Splunk Observability Cloud to an attacker-controlled host, thereby disclosing the configured Observability Cloud API token. The flaw exists because the app does not fully validate the destination of outbound requests; the request is triggered through the REST API, requires no user interaction, and is rated CVSS 6.5 (CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N), indicating a high-confidentiality but no integrity or availability impact. Exploitation is gated by a non-default capability, by the presence of the Observability Cloud app, and by an environment where an API token is configured; Splunk Enterprise 9.4.x is explicitly unaffected. No public exploit code and no confirmed active exploitation were identified at time of analysis, and a vendor patch is available.
Authenticated Splunk Enterprise users whose roles carry the run_collect capability can inject attacker-controlled content into system-level messages on the affected instance because the collect Search Processing Language (SPL) command fails to validate the index name before processing it. The flaw affects Splunk Enterprise 10.4 before 10.4.3, 10.2 before 10.2.7, 10.0 before 10.0.10, and 9.4 before 9.4.15, and is limited to a low integrity impact (CVSS 4.3, CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:L/A:N) with no confidentiality or availability loss and no user interaction required. Exploitation requires valid credentials plus a role granting run_collect - a non-default prerequisite that standard or restricted roles lack - and no public exploit has been identified at time of analysis; vendor patches are available, and this is a low-priority issue despite being network-reachable.
Splunk Secure Gateway (an app bundled with Splunk Enterprise) fails to verify that a requesting user is authorized to ask for a payload signature, so any authenticated Splunk user who does not hold the 'admin' or 'power' roles can coerce the gateway into signing attacker-controlled content. Affected builds are Splunk Enterprise versions below 10.4.3, 10.2.7, 10.0.10, and 9.4.15, together with Splunk Secure Gateway versions below 3.10.11, 3.9.25, and 3.8.72, as catalogued under CPE cpe:2.3:a:splunk:splunk_secure_gateway and cpe:2.3:a:splunk:splunk_enterprise. The impact is integrity-only (CVSS 4.3, AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:L/A:N): no confidentiality or availability effect, authenticated access and network reachability to the gateway are required, and there is no public exploit identified at time of analysis. Exploitation is confirmed as not appearing in CISA KEV, so the practical risk is confined to deployments where platform-signed payloads are subsequently trusted by downstream consumers.
Denial of service in Splunk Enterprise 10.x allows an authenticated user with only low-privileged roles to degrade or take down a REST API endpoint exposed by the Discover Splunk Observability Cloud app, because the app validates input with an inefficient regular expression that can be driven into excessive CPU consumption. Affected branches are 10.4.x below 10.4.3, 10.2.x below 10.2.7, and 10.0.x below 10.0.10; Splunk Enterprise 9.4.x is explicitly not affected, and the exposure only exists where the Observability Cloud preview app and its endpoint are present and reachable. Impact is confined to availability (no data disclosure or modification), no public exploit code has been identified at time of analysis, and the vendor has released fixes in 10.4.3, 10.2.7, and 10.0.10.
SQL injection in the SPL2 module filtering feature of Splunk Enterprise (10.4.x below 10.4.3) lets an authenticated user who holds a role with the list_spl2_modules capability read data exposed by the affected REST API, including private SPL2 module definitions owned by other users. The flaw is rooted in unparameterized user input being passed into database queries that back SPL2 module filtering, so a crafted filter value escapes the caller's intended module visibility scope; the impact is confidentiality-only with no write or availability effect, and the CVSS 3.1 vector (6.5, AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N) confirms the network-reachable but authenticated and low-privilege nature of the attack. No public exploit code has been identified at time of analysis and there is no CISA KEV listing, but a vendor patch is available in Splunk Enterprise 10.4.3, and Splunk Enterprise 10.2.x, 10.0.x, and 9.4.x are explicitly not affected.
An authenticated Splunk Enterprise user without the 'admin' or 'power' roles can read substantially all search job information belonging to other users - including raw search query text, job metadata, result sets, and preview results - by supplying a user-controlled job identifier to a REST API endpoint that fails to validate job ownership. The flaw affects Splunk Enterprise versions below 10.4.3, 10.2.7, 10.0.10, and 9.4.15, and carries a CVSS 3.1 base score of 6.5 (AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N), meaning the confidentiality impact is high but integrity and availability are untouched. No public exploit code has been identified at time of analysis and there is no confirmed active exploitation (not in CISA KEV); vendor patches are available, which reduces exposure for organizations that can upgrade promptly, though the requirement for valid low-privilege credentials limits risk to multi-user and shared-search deployments.
Authenticated log injection in Splunk Enterprise allows a user whose role carries the read_o11y_content capability to forge entries in the app log through the REST API, but only on deployments where the Splunk App for Splunk O11y Cloud is present and enabled. The root cause is CWE-117 - the app writes user-supplied SignalFlow content into the app log without neutralizing it - producing a low-impact integrity-only result (CVSS 4.3, AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:L/A:N) with no confidentiality or availability effect, and no public exploit identified at time of analysis. Only Splunk Enterprise releases below 10.4.3, 10.2.7 and 10.0.10 are affected; 9.4.x is explicitly not affected.
Missing authorization checks on multiple Splunk Secure Gateway REST API endpoints allow any authenticated Splunk user who does not hold the 'admin' or 'power' roles to reach privileged Secure Gateway functionality and make the gateway sign attacker-controlled payloads. The issue affects Splunk Enterprise versions below 10.4.3, 10.2.7, 10.0.10 and 9.4.15, as well as standalone Splunk Secure Gateway versions below 3.10.11, 3.9.25 and 3.8.72, and it requires a valid low-privilege Splunk account plus network reachability to the Secure Gateway REST API (CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:H/A:N per independent assessment; NVD publishes 6.5 with C:H/I:N). There is no public exploit identified at time of analysis and no confirmed active exploitation (CISA KEV), but a vendor patch is available and the integrity impact of forged signatures makes timely upgrade worthwhile.
Improper authorization in Splunk Enterprise (CWE-863) allows an authenticated user who does not hold the 'admin' or 'power' role to create or edit scripted lookup definitions through the raw transforms configuration write paths, which save those settings without applying the external lookup capability check that the standard lookup management UI enforces. Deployments running versions below 10.4.2, 10.2.6, 10.0.10, or 9.4.15 are affected, and exploitation requires a valid low-privilege account plus network access to the Splunk management/REST interface. The assessed CVSS 3.1 base score is 4.3 (AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:L/A:N), a moderate integrity-only authorization flaw; no public exploit code has been identified at time of analysis and the issue is not listed in CISA KEV.
Arbitrary file deletion on Splunk cluster managers is possible for any authenticated, low-privileged user - no admin or power role required - by submitting a crafted knowledge bundle delta containing path traversal sequences. Affected versions span four active release branches: 9.4.x before 9.4.14, 10.0.x before 10.0.9, 10.2.x before 10.2.6, and 10.4.x before 10.4.2. An attacker exploiting this flaw can delete files accessible to the Splunk process outside the intended staging directory, degrading system integrity or triggering service disruption on the cluster manager node. No public exploit code or CISA KEV listing has been identified at time of analysis.
SPL injection in Splunk Enterprise below versions 10.2.6, 10.0.9, and 9.4.14 enables an unauthenticated attacker to execute arbitrary Search Processing Language commands under the privileges of any authenticated Splunk user by luring that user into clicking a specially crafted Splunk Web URL. The root cause is unsanitized substitution of URL-supplied form token values directly into SPL searches, effectively turning the victim's browser session into a proxy for the attacker's queries. No public exploit code or CISA KEV listing has been identified at time of analysis, but the high confidentiality impact (C:H) makes this a meaningful data-exfiltration vector in targeted phishing scenarios against Splunk-heavy SOC or analytics environments.
Search Head Cluster member control endpoints in Splunk Enterprise fail to enforce HTTP method-based authorization, allowing a user holding the high-privilege `list_search_head_clustering` capability to send read-typed HTTP requests that alter cluster state and cause a denial of service. Four release branches are affected - 9.4.x, 10.0.x, 10.2.x, and 10.4.x - with fixed versions available from Splunk (SVD-2026-0801). No public exploit code or CISA KEV active-exploitation listing has been identified at time of analysis; exploitation is constrained to authenticated insiders or post-compromise attackers holding a high-privilege Splunk role.
Server-Side Request Forgery in Splunk Enterprise and Splunk Secure Gateway allows low-privileged authenticated users to manipulate internal Splunk services via crafted report notification paths. Affected versions span Splunk Enterprise below 10.4.2, 10.2.6, 10.0.9, and 9.4.14, and Splunk Secure Gateway below 3.10.9, 3.9.23, and 3.8.70. An attacker holding any valid Splunk account - excluding admin and power roles - can leverage the unvalidated path handling in Secure Gateway to issue system-authenticated internal requests, potentially disrupting Search Head Cluster state or causing denial of service. No public exploit code exists and this vulnerability is not listed in the CISA KEV catalog at time of analysis.
Stored cross-site scripting in Splunk Enterprise allows a 'power' role user to embed malicious JavaScript within dashboard sparkline format options, which then executes in the browser of any user who views that dashboard. If the victim holds the 'admin' Splunk role, the attacker effectively gains access to all data accessible through Splunk Web and can perform actions at admin-level permissions. Exploitation requires social engineering - the victim must be tricked into navigating to the malicious dashboard - and no public exploit code has been identified at time of analysis. Affected versions span four active release branches below 10.4.2, 10.2.6, 10.0.9, and 9.4.14.
Remote code execution in Splunk Enterprise 10.4.x allows a high-privilege user with search head cluster (SHC) management rights to write files to arbitrary locations accessible by the Splunk service account via the SHC member bundle REST API. The API fails to enforce authorization boundaries and does not validate bundle paths before accepting content, enabling path-traversal-style writes that can deliver and trigger malicious payloads. No public exploit code or active exploitation (CISA KEV) has been identified at time of analysis, but the RCE primitive makes this a meaningful risk in environments running Splunk 10.4 or 10.4.1 where high-privilege insider or compromised-account scenarios are plausible.
SQL injection in Splunk Enterprise's Data Orchestration jobs endpoint allows any authenticated low-privilege user - explicitly excluding the need for 'admin' or 'power' roles - to execute arbitrary SQL against the underlying Data Orchestration database, exposing all job records across all users and stored connection credentials. Affected version branches are 10.4.x below 10.4.2, 10.2.x below 10.2.6, 10.0.x below 10.0.9, and 9.4.x below 9.4.14. Reported by Cisco; no KEV listing or public exploit code identified at time of analysis, though the credential exposure component significantly elevates real-world impact beyond the moderate 6.5 CVSS score suggests.
Splunk Enterprise contains a stored SPL injection flaw in the Table Editor that allows a lower-privileged 'power' role user to plant risky Search Processing Language commands inside a shared dataset, which then execute silently under an 'admin' user's elevated permissions when that admin opens the dataset's Initial Data step. Affected versions span four release lines: below 10.4.2, 10.2.6, 10.0.9, and 9.4.14. A successful attack exposes all data accessible to the admin and allows modification of Splunk lookup files. No public exploit has been identified at time of analysis, and CISA KEV does not list this vulnerability as actively exploited.
Splunk Enterprise's Table Editor dataset feature permits a 'power' role user to inject attacker-controlled Search Processing Language (SPL) into a shared dataset, which silently executes with admin-level permissions when an administrator opens the dataset. Affected deployments span four version branches: 9.4 prior to 9.4.14, 10.0 prior to 10.0.9, 10.2 prior to 10.2.6, and 10.4 prior to 10.4.2. Because the Table Editor omits SPL safeguards for risky commands during the initial data preparation phase (CWE-863), a successfully phished admin can unwittingly expose all search-head-accessible data and allow limited data modification. No public exploit is identified at time of analysis, and the vulnerability does not appear in CISA's KEV catalog.
Unauthenticated token-signing key reload in Splunk Enterprise 10.4.x (below 10.4.2) exposes a REST API endpoint that lacks the required `change_authentication` capability check, permitting any network-reachable caller to force a key reload cycle without credentials. The flaw is classified under CWE-862 (Missing Authorization) and was reported by Cisco; a vendor patch is available at 10.4.2. No active exploitation has been confirmed and no public exploit code has been identified at time of analysis, though the low-complexity, unauthenticated network vector makes opportunistic probing straightforward once the endpoint is known.
SPL command injection through the geostats command in Splunk Enterprise allows an authenticated low-privileged attacker to execute arbitrary Search Processing Language commands under the security context of a second, higher-privileged victim user. Affected release branches include 10.4.x below 10.4.2, 10.2.x below 10.2.6, 10.0.x below 10.0.9, and 9.4.x below 9.4.14. Exploitation requires phishing an authenticated target into initiating the attacker-controlled search in Splunk Web; no public exploit has been identified at time of analysis and the vulnerability is not listed in the CISA KEV catalog.
Path traversal in Splunk Enterprise exposes JavaScript files outside the Splunk Web static directory to unauthenticated remote attackers across four active release branches. Splunk Web fails to enforce boundaries on static file requests, allowing directory traversal reads without any credentials. No public exploit code has been identified at time of analysis and this vulnerability is not listed in the CISA KEV catalog, but the trivially low attack complexity (AC:L, PR:N, UI:N) means exploitation requires no special tooling.
Dashboard Studio workflow actions in Splunk Enterprise can be weaponized by a 'power'-role user to store attacker-controlled SPL that executes under a victim's permission context when triggered via Event Actions. Affected versions span all major branches: 9.4 below 9.4.14, 10.0 below 10.0.9, 10.2 below 10.2.6, and 10.4 below 10.4.2. No public exploit code or CISA KEV listing exists at time of analysis, but successful exploitation enables unauthorized read and write access to data within the victim's Splunk permission scope.
Reflected SPL injection in Splunk Enterprise's Monitoring Console allows an unauthenticated attacker to execute attacker-controlled Search Processing Language queries under the permissions of a targeted Splunk administrator. The attacker must phish an admin-role user into opening a specially crafted link (CVSS UI:R/AC:H), making opportunistic mass exploitation unlikely, but a successful attack can expose all data indexed and accessible to that admin or corrupt lookup tables. Vendor-released patches are available for all affected branches; no public exploit code and no CISA KEV listing have been identified at time of analysis.