Splunk Enterprise
Monthly
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.
We need to parse the CVE data and synthesize into the required JSON fields. Let's go through each field. - product_name: 1-3 words. Affected products are Splunk Enterprise and Splunk Cloud Platform. The primary product could be "Splunk Enterprise" as the most common on-prem product, but description lists both. We can say "Splunk Enterprise" or "Splunk Cloud Platform". Since the vulnerability is in the apptemp directory handling and it's a low-privileged user with RCE, I'll pick "Splunk Enterprise" as the core product name. However, "Splunk" alone might be too generic, but allowed 1-3 words. So "Splunk Enterprise" is fine. - summary: 2-3 sentences plain-language, not copy of description. Must start with impact verb. Impact is RCE, so something like "Remote code execution in Splunk Enterprise and Splunk Cloud Platform allows...". Specific: low-privileged user (not admin/power) uploads malicious file to apptemp directory due to improper handling, leading to RCE. Affected versions: Enterprise below 10.2.1, 10.0.5, 9.4.10, 9.3.11; Cloud below various versions. Attacker can execute arbitrary code. EPSS low (0.13%), no KEV, no POC mentioned? Tags don't say POC. SSVC says exploitation none, automatable no, total impact. So not actively exploited. Summary: "Remote code execution in Splunk Enterprise and Splunk Cloud Platform allows low-privileged users without admin/power roles to execute arbitrary code by uploading a malicious file to the $SPLUNK_HOME/var/run/splunk/apptemp directory. Affects Enterprise versions before 9.3.11, 9.4.10, 10.0.5, 10.2.1 and Cloud Platform before respective fixed versions. No public exploit identified at time of analysis." - technical_context: underlying technology/protocol: Splunk apptemp directory is a temporary file storage used during app installation or updates. CWE-377 is Insecure Temporary File handling. The root cause is insufficient isolation: files in apptemp can be manipulated by low-privileged users to achieve RCE. CPEs indicate both Splunk Enterprise and Cloud Platform. Could explain that Splunk uses this directory for app staging, and improper handling of file permissions allows malicious upload to trigger code execution, possibly through app validation or loading mechanisms. Educational. - risk_assessment: CVSS 7.1, vector AV:N/AC:H/PR:L/UI:R/S:U/C:H/I:H/A:H. So network attack, high complexity, low privileges required, user interaction required, scope unchanged, high impact on CIA. EPSS 0.13% (low probability of exploitation, 33rd percentile). Not in KEV. No POC evidence. SSVC: exploitation none, automatable no, technical impact total. So risk is moderate but not actively exploited. Complexity high and user interaction required reduce real-world risk. But total impact, so if exploited, serious. Compare: CVSS is high severity (7.1) but EPSS suggests low exploitation likelihood. Patches available. Real-world priority: apply patches as part of normal cadence, not emergency. Mention that despite low EPSS, the total impact makes it worth remediating. - affected_products: list products with version ranges. Splunk Enterprise: below 10.2.1, 10.0.5, 9.4.10, 9.3.11. Splunk Cloud Platform: below 10.4.2603.0, 10.3.2512.5, 10.2.2510.9, 10.1.2507.19, 10.0.2503.13, 9.3.2411.127. Reference to vendor advisory: https://advisory.splunk.com/advisories/SVD-2026-0403. No bullet points. - remediation: action: upgrade to fixed versions. Provide exact versions: Enterprise: 9.3.11, 9.4.10, 10.0.5, 10.2.1; Cloud: 9.3.2411.127, 10.0.2503.13, 10.1.2507.19, 10.2.2510.9, 10.3.2512.5, 10.4.2603.0. Workaround maybe not mentioned. Possibly restrict file upload permissions or restrict access to apptemp directory. But no specific workaround in description. I'll say: "Upgrade Splunk Enterprise to version 9.3.11, 9.4.10, 10.0.5, or 10.2.1, and Splunk Cloud Platform to 9.3.2411.127, 10.0.2503.13, 10.1.2507.19, 10.2.2510.9, 10.3.2512.5, or 10.4.2603.0. As a temporary mitigation if upgrading is not possible, restrict write access to the apptemp directory to trusted roles only, but this may impact app installation functionality. Consult advisory SVD-2026-0403." - exploit_scenario: realistic attack: low-privileged Splunk user (without admin/power) uploads a malicious file to the apptemp directory (which they can access) via a crafted request or through app upload functionality if allowed; the file is then processed by Splunk in a way that leads to code execution, potentially via loading a malicious app or configuration. Attack complexity high due to need to trigger processing. Example: "A low-privileged user authenticates to Splunk Web and uploads a specially crafted file to the apptemp directory via the app import feature. When Splunk processes the temporary file for app installation, the malicious payload executes, giving the attacker remote code execution on the Splunk server." - exploitation_conditions: specific prerequisites from description: "low-privileged user that does not hold the admin or power Splunk roles". So attacker must have any low-privileged role, not power/admin. Also, the user must be able to upload a file to the `$SPLUNK_HOME/var/run/splunk/apptemp` directory. That directory might be writable by all authenticated users? The vulnerability is due to improper handling and insufficient isolation of temporary files. So condition: the Splunk instance must allow file uploads to apptemp by low-privileged users. It may be default. User interaction required (UI:R) could refer to the attacker needing to trick a user into processing? Actually UI:R in CVSS means the attacker must trick a user into taking some action. This might be that the low-privileged user must upload the file, but it's the attacker that is that user. In that case, it's not UI. Wait, CVSS says UI:R, which typically requires that the exploitation requires a user other than the attacker to take action. Could be that the attacker needs to convince a victim (another user) to upload the malicious file? The description says "a low-privileged user could potentially perform a Remote Code Execution by uploading a malicious file". That suggests the attacker is the low-privileged user themselves. So UI:R might be misinterpreted? Alternatively, the upload might be via some UI action that the attacker performs. But CVSS defines UI:R as "the vulnerable component requires user interaction to function. ... the user interaction is required from a user other than the attacker." So if the attacker themselves is the user performing the upload, then it's not UI:R but rather PR:L and no UI. The CVSS vector provided shows UI:R, but given descriptions, maybe the attacker must convince a user with low privileges to upload? Could be both: maybe the attacker can be a low-privileged user, but to trigger the RCE they need to interact with the apptemp directory in a way that involves some UI? Possibly the vulnerability is in the handling of uploaded files during app installation, which might be triggered by the user through UI. I think the vector might be AV:N/AC:H/PR:L/UI:N/..., but they put UI:R. I'll respect the given CVSS vector. So exploitation conditions: attacker must be authenticated as a low-privileged user (non-admin, non-power) and must be able to upload a file to apptemp, but also requires user interaction from another user? Perhaps the attacker uploads a file that is then executed when an admin installs or processes an app. That would be UI:R from the admin. So condition: "Exploitation requires an authenticated low-privileged user (without admin or power roles) to upload a malicious file to the apptemp directory, and a subsequent user action (e.g., by an administrator or automated process) that triggers processing of that file." But let's keep to the description. I'll state: "Requires an authenticated Splunk account with any low-privileged role (not admin or power). The attacker must be able to write files to the `$SPLUNK_HOME/var/run/splunk/apptemp` directory, which may be accessible by default. User interaction is required to trigger the RCE (CVSS UI:R), likely from another user such as an administrator performing an app management action." Also add that it's remote over network. So: "Exploitation requires authenticated access as a low-privileged user (non-admin, non-power) and the ability to upload files to the apptemp directory. No specific non-default configuration is required if the directory is writable; however, the high attack complexity and user interaction requirement imply that the attacker must either trick another user into processing the file or rely on specific workflow." - attack_chain: Based on kill chain: authenticated low-privileged user uploads malicious file to apptemp directory via Splunk Web or API → file is stored in apptemp with insufficient isolation → later, an administrator or cron job processes the file (e.g., during app installation or validation) → the malicious payload executes → attacker achieves remote code execution with Splunk service privileges. So chain: "Authenticate as low-privileged Splunk user → Upload malicious file to apptemp directory via app upload feature → Wait for file to be processed by Splunk (e.g., admin action or scheduled task) → Malicious code executes → Gain RCE on Splunk server." 5 steps. - confidence_notes: Vendor advisory exists (SVD-2026-0403) confirming affected versions and patches. EPSS score is low, no KEV. POC status unknown (not listed). The CVE description is from the advisory. SSVC indicates no exploitation, not automatable, total impact. So confidence: "Vendor-confirmed vulnerability with fixed versions published in Splunk advisory SVD-2026-0403. No evidence of public exploit or active exploitation. Affected version ranges and patch availability are confirmed. The exact mechanism of code execution and preconditions (UI:R) require further analysis." - prevalence: Splunk is a widely used enterprise SIEM and log management platform. It is common in large organizations. So prevalence likely "high". Many enterprise environments run Splunk. So "high". - prevalence_basis: "widely deployed enterprise SIEM and log management solution". - assessed_cvss_vector: I need to provide my own independent CVSS. Given the description, I might adjust. The provided CVSS is 7.1: AV:N/AC:H/PR:L/UI:R/S:U/C:H/I:H/A:H. Is that reasonable? The attack requires network, low privileges, but also user interaction. However, if the attacker is the low-privileged user and they upload a file and that immediately triggers RCE, then UI:N would be more appropriate. But the description doesn't say what triggers the RCE. Could be that the file is uploaded and then automatically processed by some Splunk internal mechanism without user interaction? The CWE-377 is Insecure Temporary File, but the vulnerability could be that the file is placed and then later processed by a service (like a cron job) that doesn't require user interaction. In that case, UI:N. However, the given vector has UI:R, which I'll respect because it's from Splunk themselves. So my assessed vector might differ. I'll reason: The attack requires the attacker to upload a file, but if the processing is automatic, then UI:N. But high complexity maybe due to file format or timing. I'll lean towards UI:N if the description doesn't mention tricking a user. But let's read: "could potentially perform a Remote Code Execution by uploading a malicious file to the $SPLUNK_HOME/var/run/splunk/apptemp directory due to improper handling". So the act of uploading is the vector. The handling is improper, so the mere upload might cause RCE. That suggests no additional user interaction. So I'd set UI:N. Also, the attack complexity: maybe needs specific file content? High? Might be high if
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.
SPL injection via the dashboard PDF export feature in Splunk Enterprise allows a 'power'-role attacker to store malicious Search Processing Language that executes under the permissions of a separate, higher-privileged authenticated user when that user exports the dashboard as a PDF. Affected versions span four maintained release branches: 10.4 below 10.4.1, 10.2 below 10.2.6, 10.0 below 10.0.9, and 9.4 below 9.4.14. No public exploit code has been identified and the vulnerability does not appear in the CISA KEV catalog; successful exploitation requires chaining a held 'power' role with a successful phishing step against the victim user.
SPL injection via Splunk Secure Gateway's unsanitized dashboard URL parameters allows an unauthenticated attacker to execute arbitrary Search Processing Language commands under the full permissions of a phished Splunk administrator. The Splunk Secure Gateway component fails to neutralize caller-supplied values before embedding them in dashboard searches, meaning a crafted URL opened by an 'admin' or 'sc_admin' user causes injected SPL to run with that user's data access - potentially exposing all indexed data visible to the administrator and corrupting search results or lookup tables. No public exploit code has been identified at time of analysis and this CVE does not appear in the CISA KEV catalog, though the phishing vector and high data-access impact make this a meaningful risk for organizations with sensitive Splunk deployments.
Stored cross-site scripting in Splunk Enterprise's dashboard table renderer allows a low-privileged user - without admin or power role - to inject JavaScript payloads into sparkline table cell tooltips, which execute in the browser of any user who opens the malicious dashboard and hovers over an affected cell. The vulnerability spans four active Splunk Enterprise release lines (9.4, 10.0, 10.2, and 10.4), confirmed by EUVD-2026-63133 and Splunk advisory SVD-2026-0801. No public exploit code or active exploitation has been identified at time of analysis, but the broad version coverage and low attacker privilege bar make patching a clear operational priority.
Stored cross-site scripting in Splunk Enterprise's guided tour feature enables a 'power'-role user to inject and execute arbitrary JavaScript in any other authenticated user's browser when that user opens a crafted tour link. Affected across four active release branches (9.4.x, 10.0.x, 10.2.x, 10.4.x) with fixed versions now available per Splunk advisory SVD-2026-0801. No public exploit code or CISA KEV listing exists at time of analysis; the CVSS score of 5.7 reflects the dual prerequisite of attacker role access and required victim interaction.
Cross-site request forgery combined with SPL injection in Splunk Enterprise's Event Type Builder allows an unauthenticated attacker to cause an authenticated user to execute arbitrary Search Processing Language queries under the victim's session context. Affected release branches span versions below 10.4.2, 10.2.6, 10.0.9, and 9.4.14, covering multiple concurrent support tracks. Successful exploitation can expose all data accessible to the victim's Splunk session including stored credentials, though the attacker must first phish an authenticated user into initiating the malicious browser request. No public exploit has been identified at time of analysis, and the vulnerability is not listed in the CISA KEV catalog.
Stored cross-site scripting in Splunk Enterprise exposes victim user data when a user holding the schedule_search capability injects a malicious script into an alert trigger condition field and induces another user to open the crafted link. The script executes in the victim's browser context and can access all Splunk data available to that user, making this particularly dangerous in environments where analysts or admins have broad search access over sensitive logs and security telemetry. Patch is available from Splunk across four version branches; no public exploit or CISA KEV listing has been identified at time of analysis.
SQL injection in Splunk Enterprise's REST API allows low-privileged authenticated users to embed attacker-controlled SQL fragments into backend database queries, potentially exposing data beyond their authorized scope. Four actively maintained version branches are affected - 9.4.x, 10.0.x, 10.2.x, and 10.4.x - with patched releases available across all branches per the vendor advisory SVD-2026-0801. The CVSS score of 4.3 reflects a read-only confidentiality impact (C:L/I:N/A:N) with no public exploit identified at time of analysis, though the attack pattern is well-understood and the REST API is network-accessible by default.
Broken object level authorization (BOLA) in Splunk Enterprise's data management orchestrator allows authenticated low-privileged users to delete SPL2 modules owned by other users. Affected versions are Splunk Enterprise 10.2.x before 10.2.6 and 10.4.x before 10.4.2; the feature is absent in versions prior to 10.2, so those are unaffected. No public exploit code or active exploitation has been identified at time of analysis, and a vendor-released patch is available.
Insufficient access controls on the Splunk Secure Gateway App Key Value Store REST API expose Spacebridge asymmetric private keys to any authenticated low-privilege user lacking the 'admin' or 'power' role. The exposure is conditional on instances that were upgraded from older Splunk Secure Gateway deployments where a private-key migration remained incomplete, leaving sensitive cryptographic material in a KVStore collection governed by an insecure default ACL. No public exploit code exists at time of analysis, but successful exploitation fully compromises the affected Spacebridge private-key material, enabling cryptographic impersonation or decryption of Spacebridge-protected communications.
Splunk Enterprise incorrectly gates the properties REST endpoint on the rest_properties_get capability rather than the purpose-built list_storage_passwords capability, allowing any authenticated user with that role permission to read encrypted stored credentials via the REST API. Affected branches span four active release lines: 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 per EUVD-2026-63112. No public exploit has been identified at time of analysis and this CVE is not listed in CISA KEV, but the flaw is mechanically straightforward for any user whose role carries the misassigned capability.
Splunk Secure Gateway's companion app registration handler contains a hard-coded cryptographic key, enabling any low-privileged authenticated Splunk user - explicitly excluding admin or power roles - to register an arbitrary attacker-controlled callback URL and cause Secure Gateway to forward mobile user requests and authentication tokens to that URL. Affected are Splunk Enterprise 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), alongside Splunk Secure Gateway branches 3.8 (below 3.8.71), 3.9 (below 3.9.24), and 3.10 (below 3.10.10). No public exploit code or active exploitation has been confirmed at time of analysis; however, the low attack complexity and minimal privilege requirement make this a credible insider-threat or post-compromise lateral movement vector in any environment running Splunk Mobile.
Unauthorized access to Mobile Device Management signing secrets in Splunk Secure Gateway allows a low-privileged Splunk user to compromise all mobile-device enrollment trust. Affected are Splunk Enterprise below 10.4.2, 10.2.6, 10.0.9, and 9.4.14, and Splunk Secure Gateway below 3.10.10, 3.9.24, and 3.8.71. An attacker holding only the 'list storage passwords' role permission - without Secure Gateway administration privileges - can invoke unprotected REST API endpoints (deployment bundle, SAML setup, companion app workflows) to retrieve MDM signing secrets, enabling enrollment of unauthorized or attacker-controlled mobile devices. No public exploit code or CISA KEV listing has been identified at time of analysis.
Information disclosure in Splunk Enterprise and Splunk Secure Gateway exposes sensitive SAML configuration and instance settings to any authenticated low-privilege user lacking the 'admin' or 'power' role. The Splunk Secure Gateway REST API endpoints responsible for returning SAML setup data fail to enforce authorization checks, allowing role-restricted users to retrieve IdP metadata, certificates, and SSO configuration they should not access. No public exploit code or active exploitation has been identified; a vendor patch is available and remediation is straightforward.
Cross-site scripting in Splunk Enterprise (below versions 10.4.2, 10.2.6, 10.0.9, and 9.4.13) enables an unauthenticated attacker to execute arbitrary JavaScript in an authenticated user's browser by tricking that user into visiting a malicious web page. Splunk Web's page message handler processes incoming postMessage events without validating their origin or source, allowing cross-origin script injection into the victim's active Splunk session. Successful exploitation can expose all data accessible to the victim user and permit unauthorized actions affecting system integrity; no public exploit code or CISA KEV listing has been identified at time of analysis.
Credential hash exposure in Splunk Enterprise and Splunk Cloud Platform allows low-privileged users - those without the 'admin' or 'power' roles - to retrieve stored credential hashes by issuing the `|rest` SPL command against the `/servicesNS/-/-/storage/passwords` endpoint, which incorrectly returns the `encr_password` field. Affected are Splunk Enterprise branches below 10.4.1, 10.2.5, 10.0.8, and 9.4.13, and multiple Splunk Cloud Platform versions. No public exploit has been identified at time of analysis and this CVE is not in CISA KEV, but the real-world impact is significant wherever Splunk stores credentials for external services such as databases, APIs, or cloud accounts.
Stored cross-site scripting in Splunk Enterprise (below 10.2.4, 10.0.7, 9.4.12, 9.3.13) and Splunk Cloud Platform (below 10.3.2512.11, 10.2.2510.15, 10.1.2507.23, 9.3.2411.132) allows a low-privileged authenticated user - without 'admin' or 'power' roles - to embed malicious JavaScript inside a classic dashboard HTML panel that executes in another user's browser session. Exploitation requires phishing the victim into initiating a specific browser request, and no public exploit was identified at time of analysis.
Classic dashboard style attribute injection in Splunk Enterprise and Splunk Cloud Platform enables a low-privileged authenticated user to craft panels that bypass the Trusted Domains List and exfiltrate sensitive data from a higher-privileged user's browser session. Affected branches span Splunk Enterprise below 10.2.4, 10.0.7, 9.4.12, and 9.3.13, and multiple Splunk Cloud Platform release trains. No public exploit has been identified at time of analysis, and SSVC rates current exploitation as none with partial technical impact, though the high confidentiality impact potential warrants prompt patching in environments where low-privileged users can share dashboards with administrators.
Improper access control on the saved search ownership reassignment endpoint in Splunk Enterprise and Splunk Cloud Platform allows a highly privileged authenticated user - one whose role contains the `edit_saved_search_owner` capability - to reassign saved search ownership to users outside their authorized scope. Affected versions span Splunk Enterprise below 10.2.4 and 10.0.7, and multiple Splunk Cloud Platform branches below their respective fixed builds. No public exploit has been identified at time of analysis, and the PR:H CVSS requirement confines risk primarily to insider threats or scenarios involving compromised privileged Splunk accounts.
Classic dashboard URL validation bypass in Splunk Enterprise and Splunk Cloud Platform enables low-privileged authenticated users to craft dashboards that silently exfiltrate sensitive data to attacker-controlled external servers. The flaw (CWE-20) resides in the external content dialog, which fails to enforce complete domain restrictions, allowing outbound requests to untrusted hosts when a victim interacts with the malicious dashboard. No public exploit exists and this vulnerability is not listed in CISA KEV, but the High confidentiality impact (C:H) in the CVSS vector reflects meaningful data exposure risk in environments where Splunk indexes security events, credentials, or sensitive operational logs.
CSS injection in Splunk Enterprise and Splunk Cloud Platform classic dashboards enables credential and sensitive data exfiltration by low-privileged users targeting higher-privileged accounts. A low-privileged user (without 'admin' or 'power' roles) can craft a malicious classic dashboard containing injected CSS via inline style attributes; when a higher-privileged user views the dashboard, outbound HTTP requests are triggered to attacker-controlled external servers, bypassing the Trusted Domains restriction. No public exploit has been identified at time of analysis and the vulnerability is not listed in the CISA KEV catalog, but the C:H confidentiality impact and cross-privilege exploitation path make this a meaningful insider or compromised-account threat in environments with mixed privilege levels.
Classic dashboard drill-down links in Splunk Enterprise and Splunk Cloud Platform can be weaponized by low-privileged authenticated users to silently redirect victims to attacker-controlled external sites, enabling data exfiltration. The flaw stems from an incomplete URL scheme validator that recognizes only 'http://' and 'https://' prefixes, allowing protocol-relative URLs like '//attacker.com' to bypass the external-navigation warning dialog entirely. No public exploit code exists and no active exploitation is confirmed (not in CISA KEV), but the attack requires only a low-privileged account and a single victim click, making it a realistic phishing vector in multi-tenant or large enterprise Splunk deployments.
Sensitive information disclosure in Splunk Enterprise (below 10.2.2 and 10.0.5) and Splunk Cloud Platform (multiple branches below 10.3.2512.8, 10.2.2510.11, 10.1.2507.21, and 10.0.2503.13) allows authenticated users with a role granting access to the `_internal` index to view session cookies and response bodies containing sensitive data logged by the platform. Cisco-reported and patched by Splunk in advisory SVD-2026-0503, the issue is a CWE-532 sensitive-data-in-logs flaw rather than a remote code execution bug, with no public exploit identified at time of analysis.
Denial of Service in Splunk Enterprise and Splunk Cloud Platform allows a low-privileged authenticated user to render the entire instance non-functional by exploiting missing input validation in the `coldToFrozen.sh` script bundled with the `splunk_archiver` app. The script accepts arbitrary file paths and renames them without restricting operations to safe directories, enabling renaming of critical Splunk system directories. No public exploit or CISA KEV listing has been identified at time of analysis, but the low privilege requirement (PR:L per CVSS) makes this actionable for any authenticated non-admin user in multi-tenant or enterprise deployments. A vendor patch is available via advisory SVD-2026-0504.
Improper access control in Splunk Enterprise
Account management inconsistencies in Splunk Enterprise and Splunk Cloud Platform allow users with the high-privilege 'edit_user' capability to create specially crafted usernames containing null bytes or non-UTF-8 percent-encoded bytes. This can lead to improper storage of usernames, resulting in inability to edit or delete affected users. No active exploitation has been identified and the EPSS score is very low (0.04%), indicating minimal real-world risk.
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.
We need to parse the CVE data and synthesize into the required JSON fields. Let's go through each field. - product_name: 1-3 words. Affected products are Splunk Enterprise and Splunk Cloud Platform. The primary product could be "Splunk Enterprise" as the most common on-prem product, but description lists both. We can say "Splunk Enterprise" or "Splunk Cloud Platform". Since the vulnerability is in the apptemp directory handling and it's a low-privileged user with RCE, I'll pick "Splunk Enterprise" as the core product name. However, "Splunk" alone might be too generic, but allowed 1-3 words. So "Splunk Enterprise" is fine. - summary: 2-3 sentences plain-language, not copy of description. Must start with impact verb. Impact is RCE, so something like "Remote code execution in Splunk Enterprise and Splunk Cloud Platform allows...". Specific: low-privileged user (not admin/power) uploads malicious file to apptemp directory due to improper handling, leading to RCE. Affected versions: Enterprise below 10.2.1, 10.0.5, 9.4.10, 9.3.11; Cloud below various versions. Attacker can execute arbitrary code. EPSS low (0.13%), no KEV, no POC mentioned? Tags don't say POC. SSVC says exploitation none, automatable no, total impact. So not actively exploited. Summary: "Remote code execution in Splunk Enterprise and Splunk Cloud Platform allows low-privileged users without admin/power roles to execute arbitrary code by uploading a malicious file to the $SPLUNK_HOME/var/run/splunk/apptemp directory. Affects Enterprise versions before 9.3.11, 9.4.10, 10.0.5, 10.2.1 and Cloud Platform before respective fixed versions. No public exploit identified at time of analysis." - technical_context: underlying technology/protocol: Splunk apptemp directory is a temporary file storage used during app installation or updates. CWE-377 is Insecure Temporary File handling. The root cause is insufficient isolation: files in apptemp can be manipulated by low-privileged users to achieve RCE. CPEs indicate both Splunk Enterprise and Cloud Platform. Could explain that Splunk uses this directory for app staging, and improper handling of file permissions allows malicious upload to trigger code execution, possibly through app validation or loading mechanisms. Educational. - risk_assessment: CVSS 7.1, vector AV:N/AC:H/PR:L/UI:R/S:U/C:H/I:H/A:H. So network attack, high complexity, low privileges required, user interaction required, scope unchanged, high impact on CIA. EPSS 0.13% (low probability of exploitation, 33rd percentile). Not in KEV. No POC evidence. SSVC: exploitation none, automatable no, technical impact total. So risk is moderate but not actively exploited. Complexity high and user interaction required reduce real-world risk. But total impact, so if exploited, serious. Compare: CVSS is high severity (7.1) but EPSS suggests low exploitation likelihood. Patches available. Real-world priority: apply patches as part of normal cadence, not emergency. Mention that despite low EPSS, the total impact makes it worth remediating. - affected_products: list products with version ranges. Splunk Enterprise: below 10.2.1, 10.0.5, 9.4.10, 9.3.11. Splunk Cloud Platform: below 10.4.2603.0, 10.3.2512.5, 10.2.2510.9, 10.1.2507.19, 10.0.2503.13, 9.3.2411.127. Reference to vendor advisory: https://advisory.splunk.com/advisories/SVD-2026-0403. No bullet points. - remediation: action: upgrade to fixed versions. Provide exact versions: Enterprise: 9.3.11, 9.4.10, 10.0.5, 10.2.1; Cloud: 9.3.2411.127, 10.0.2503.13, 10.1.2507.19, 10.2.2510.9, 10.3.2512.5, 10.4.2603.0. Workaround maybe not mentioned. Possibly restrict file upload permissions or restrict access to apptemp directory. But no specific workaround in description. I'll say: "Upgrade Splunk Enterprise to version 9.3.11, 9.4.10, 10.0.5, or 10.2.1, and Splunk Cloud Platform to 9.3.2411.127, 10.0.2503.13, 10.1.2507.19, 10.2.2510.9, 10.3.2512.5, or 10.4.2603.0. As a temporary mitigation if upgrading is not possible, restrict write access to the apptemp directory to trusted roles only, but this may impact app installation functionality. Consult advisory SVD-2026-0403." - exploit_scenario: realistic attack: low-privileged Splunk user (without admin/power) uploads a malicious file to the apptemp directory (which they can access) via a crafted request or through app upload functionality if allowed; the file is then processed by Splunk in a way that leads to code execution, potentially via loading a malicious app or configuration. Attack complexity high due to need to trigger processing. Example: "A low-privileged user authenticates to Splunk Web and uploads a specially crafted file to the apptemp directory via the app import feature. When Splunk processes the temporary file for app installation, the malicious payload executes, giving the attacker remote code execution on the Splunk server." - exploitation_conditions: specific prerequisites from description: "low-privileged user that does not hold the admin or power Splunk roles". So attacker must have any low-privileged role, not power/admin. Also, the user must be able to upload a file to the `$SPLUNK_HOME/var/run/splunk/apptemp` directory. That directory might be writable by all authenticated users? The vulnerability is due to improper handling and insufficient isolation of temporary files. So condition: the Splunk instance must allow file uploads to apptemp by low-privileged users. It may be default. User interaction required (UI:R) could refer to the attacker needing to trick a user into processing? Actually UI:R in CVSS means the attacker must trick a user into taking some action. This might be that the low-privileged user must upload the file, but it's the attacker that is that user. In that case, it's not UI. Wait, CVSS says UI:R, which typically requires that the exploitation requires a user other than the attacker to take action. Could be that the attacker needs to convince a victim (another user) to upload the malicious file? The description says "a low-privileged user could potentially perform a Remote Code Execution by uploading a malicious file". That suggests the attacker is the low-privileged user themselves. So UI:R might be misinterpreted? Alternatively, the upload might be via some UI action that the attacker performs. But CVSS defines UI:R as "the vulnerable component requires user interaction to function. ... the user interaction is required from a user other than the attacker." So if the attacker themselves is the user performing the upload, then it's not UI:R but rather PR:L and no UI. The CVSS vector provided shows UI:R, but given descriptions, maybe the attacker must convince a user with low privileges to upload? Could be both: maybe the attacker can be a low-privileged user, but to trigger the RCE they need to interact with the apptemp directory in a way that involves some UI? Possibly the vulnerability is in the handling of uploaded files during app installation, which might be triggered by the user through UI. I think the vector might be AV:N/AC:H/PR:L/UI:N/..., but they put UI:R. I'll respect the given CVSS vector. So exploitation conditions: attacker must be authenticated as a low-privileged user (non-admin, non-power) and must be able to upload a file to apptemp, but also requires user interaction from another user? Perhaps the attacker uploads a file that is then executed when an admin installs or processes an app. That would be UI:R from the admin. So condition: "Exploitation requires an authenticated low-privileged user (without admin or power roles) to upload a malicious file to the apptemp directory, and a subsequent user action (e.g., by an administrator or automated process) that triggers processing of that file." But let's keep to the description. I'll state: "Requires an authenticated Splunk account with any low-privileged role (not admin or power). The attacker must be able to write files to the `$SPLUNK_HOME/var/run/splunk/apptemp` directory, which may be accessible by default. User interaction is required to trigger the RCE (CVSS UI:R), likely from another user such as an administrator performing an app management action." Also add that it's remote over network. So: "Exploitation requires authenticated access as a low-privileged user (non-admin, non-power) and the ability to upload files to the apptemp directory. No specific non-default configuration is required if the directory is writable; however, the high attack complexity and user interaction requirement imply that the attacker must either trick another user into processing the file or rely on specific workflow." - attack_chain: Based on kill chain: authenticated low-privileged user uploads malicious file to apptemp directory via Splunk Web or API → file is stored in apptemp with insufficient isolation → later, an administrator or cron job processes the file (e.g., during app installation or validation) → the malicious payload executes → attacker achieves remote code execution with Splunk service privileges. So chain: "Authenticate as low-privileged Splunk user → Upload malicious file to apptemp directory via app upload feature → Wait for file to be processed by Splunk (e.g., admin action or scheduled task) → Malicious code executes → Gain RCE on Splunk server." 5 steps. - confidence_notes: Vendor advisory exists (SVD-2026-0403) confirming affected versions and patches. EPSS score is low, no KEV. POC status unknown (not listed). The CVE description is from the advisory. SSVC indicates no exploitation, not automatable, total impact. So confidence: "Vendor-confirmed vulnerability with fixed versions published in Splunk advisory SVD-2026-0403. No evidence of public exploit or active exploitation. Affected version ranges and patch availability are confirmed. The exact mechanism of code execution and preconditions (UI:R) require further analysis." - prevalence: Splunk is a widely used enterprise SIEM and log management platform. It is common in large organizations. So prevalence likely "high". Many enterprise environments run Splunk. So "high". - prevalence_basis: "widely deployed enterprise SIEM and log management solution". - assessed_cvss_vector: I need to provide my own independent CVSS. Given the description, I might adjust. The provided CVSS is 7.1: AV:N/AC:H/PR:L/UI:R/S:U/C:H/I:H/A:H. Is that reasonable? The attack requires network, low privileges, but also user interaction. However, if the attacker is the low-privileged user and they upload a file and that immediately triggers RCE, then UI:N would be more appropriate. But the description doesn't say what triggers the RCE. Could be that the file is uploaded and then automatically processed by some Splunk internal mechanism without user interaction? The CWE-377 is Insecure Temporary File, but the vulnerability could be that the file is placed and then later processed by a service (like a cron job) that doesn't require user interaction. In that case, UI:N. However, the given vector has UI:R, which I'll respect because it's from Splunk themselves. So my assessed vector might differ. I'll reason: The attack requires the attacker to upload a file, but if the processing is automatic, then UI:N. But high complexity maybe due to file format or timing. I'll lean towards UI:N if the description doesn't mention tricking a user. But let's read: "could potentially perform a Remote Code Execution by uploading a malicious file to the $SPLUNK_HOME/var/run/splunk/apptemp directory due to improper handling". So the act of uploading is the vector. The handling is improper, so the mere upload might cause RCE. That suggests no additional user interaction. So I'd set UI:N. Also, the attack complexity: maybe needs specific file content? High? Might be high if
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.
SPL injection via the dashboard PDF export feature in Splunk Enterprise allows a 'power'-role attacker to store malicious Search Processing Language that executes under the permissions of a separate, higher-privileged authenticated user when that user exports the dashboard as a PDF. Affected versions span four maintained release branches: 10.4 below 10.4.1, 10.2 below 10.2.6, 10.0 below 10.0.9, and 9.4 below 9.4.14. No public exploit code has been identified and the vulnerability does not appear in the CISA KEV catalog; successful exploitation requires chaining a held 'power' role with a successful phishing step against the victim user.
SPL injection via Splunk Secure Gateway's unsanitized dashboard URL parameters allows an unauthenticated attacker to execute arbitrary Search Processing Language commands under the full permissions of a phished Splunk administrator. The Splunk Secure Gateway component fails to neutralize caller-supplied values before embedding them in dashboard searches, meaning a crafted URL opened by an 'admin' or 'sc_admin' user causes injected SPL to run with that user's data access - potentially exposing all indexed data visible to the administrator and corrupting search results or lookup tables. No public exploit code has been identified at time of analysis and this CVE does not appear in the CISA KEV catalog, though the phishing vector and high data-access impact make this a meaningful risk for organizations with sensitive Splunk deployments.
Stored cross-site scripting in Splunk Enterprise's dashboard table renderer allows a low-privileged user - without admin or power role - to inject JavaScript payloads into sparkline table cell tooltips, which execute in the browser of any user who opens the malicious dashboard and hovers over an affected cell. The vulnerability spans four active Splunk Enterprise release lines (9.4, 10.0, 10.2, and 10.4), confirmed by EUVD-2026-63133 and Splunk advisory SVD-2026-0801. No public exploit code or active exploitation has been identified at time of analysis, but the broad version coverage and low attacker privilege bar make patching a clear operational priority.
Stored cross-site scripting in Splunk Enterprise's guided tour feature enables a 'power'-role user to inject and execute arbitrary JavaScript in any other authenticated user's browser when that user opens a crafted tour link. Affected across four active release branches (9.4.x, 10.0.x, 10.2.x, 10.4.x) with fixed versions now available per Splunk advisory SVD-2026-0801. No public exploit code or CISA KEV listing exists at time of analysis; the CVSS score of 5.7 reflects the dual prerequisite of attacker role access and required victim interaction.
Cross-site request forgery combined with SPL injection in Splunk Enterprise's Event Type Builder allows an unauthenticated attacker to cause an authenticated user to execute arbitrary Search Processing Language queries under the victim's session context. Affected release branches span versions below 10.4.2, 10.2.6, 10.0.9, and 9.4.14, covering multiple concurrent support tracks. Successful exploitation can expose all data accessible to the victim's Splunk session including stored credentials, though the attacker must first phish an authenticated user into initiating the malicious browser request. No public exploit has been identified at time of analysis, and the vulnerability is not listed in the CISA KEV catalog.
Stored cross-site scripting in Splunk Enterprise exposes victim user data when a user holding the schedule_search capability injects a malicious script into an alert trigger condition field and induces another user to open the crafted link. The script executes in the victim's browser context and can access all Splunk data available to that user, making this particularly dangerous in environments where analysts or admins have broad search access over sensitive logs and security telemetry. Patch is available from Splunk across four version branches; no public exploit or CISA KEV listing has been identified at time of analysis.
SQL injection in Splunk Enterprise's REST API allows low-privileged authenticated users to embed attacker-controlled SQL fragments into backend database queries, potentially exposing data beyond their authorized scope. Four actively maintained version branches are affected - 9.4.x, 10.0.x, 10.2.x, and 10.4.x - with patched releases available across all branches per the vendor advisory SVD-2026-0801. The CVSS score of 4.3 reflects a read-only confidentiality impact (C:L/I:N/A:N) with no public exploit identified at time of analysis, though the attack pattern is well-understood and the REST API is network-accessible by default.
Broken object level authorization (BOLA) in Splunk Enterprise's data management orchestrator allows authenticated low-privileged users to delete SPL2 modules owned by other users. Affected versions are Splunk Enterprise 10.2.x before 10.2.6 and 10.4.x before 10.4.2; the feature is absent in versions prior to 10.2, so those are unaffected. No public exploit code or active exploitation has been identified at time of analysis, and a vendor-released patch is available.
Insufficient access controls on the Splunk Secure Gateway App Key Value Store REST API expose Spacebridge asymmetric private keys to any authenticated low-privilege user lacking the 'admin' or 'power' role. The exposure is conditional on instances that were upgraded from older Splunk Secure Gateway deployments where a private-key migration remained incomplete, leaving sensitive cryptographic material in a KVStore collection governed by an insecure default ACL. No public exploit code exists at time of analysis, but successful exploitation fully compromises the affected Spacebridge private-key material, enabling cryptographic impersonation or decryption of Spacebridge-protected communications.
Splunk Enterprise incorrectly gates the properties REST endpoint on the rest_properties_get capability rather than the purpose-built list_storage_passwords capability, allowing any authenticated user with that role permission to read encrypted stored credentials via the REST API. Affected branches span four active release lines: 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 per EUVD-2026-63112. No public exploit has been identified at time of analysis and this CVE is not listed in CISA KEV, but the flaw is mechanically straightforward for any user whose role carries the misassigned capability.
Splunk Secure Gateway's companion app registration handler contains a hard-coded cryptographic key, enabling any low-privileged authenticated Splunk user - explicitly excluding admin or power roles - to register an arbitrary attacker-controlled callback URL and cause Secure Gateway to forward mobile user requests and authentication tokens to that URL. Affected are Splunk Enterprise 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), alongside Splunk Secure Gateway branches 3.8 (below 3.8.71), 3.9 (below 3.9.24), and 3.10 (below 3.10.10). No public exploit code or active exploitation has been confirmed at time of analysis; however, the low attack complexity and minimal privilege requirement make this a credible insider-threat or post-compromise lateral movement vector in any environment running Splunk Mobile.
Unauthorized access to Mobile Device Management signing secrets in Splunk Secure Gateway allows a low-privileged Splunk user to compromise all mobile-device enrollment trust. Affected are Splunk Enterprise below 10.4.2, 10.2.6, 10.0.9, and 9.4.14, and Splunk Secure Gateway below 3.10.10, 3.9.24, and 3.8.71. An attacker holding only the 'list storage passwords' role permission - without Secure Gateway administration privileges - can invoke unprotected REST API endpoints (deployment bundle, SAML setup, companion app workflows) to retrieve MDM signing secrets, enabling enrollment of unauthorized or attacker-controlled mobile devices. No public exploit code or CISA KEV listing has been identified at time of analysis.
Information disclosure in Splunk Enterprise and Splunk Secure Gateway exposes sensitive SAML configuration and instance settings to any authenticated low-privilege user lacking the 'admin' or 'power' role. The Splunk Secure Gateway REST API endpoints responsible for returning SAML setup data fail to enforce authorization checks, allowing role-restricted users to retrieve IdP metadata, certificates, and SSO configuration they should not access. No public exploit code or active exploitation has been identified; a vendor patch is available and remediation is straightforward.
Cross-site scripting in Splunk Enterprise (below versions 10.4.2, 10.2.6, 10.0.9, and 9.4.13) enables an unauthenticated attacker to execute arbitrary JavaScript in an authenticated user's browser by tricking that user into visiting a malicious web page. Splunk Web's page message handler processes incoming postMessage events without validating their origin or source, allowing cross-origin script injection into the victim's active Splunk session. Successful exploitation can expose all data accessible to the victim user and permit unauthorized actions affecting system integrity; no public exploit code or CISA KEV listing has been identified at time of analysis.
Credential hash exposure in Splunk Enterprise and Splunk Cloud Platform allows low-privileged users - those without the 'admin' or 'power' roles - to retrieve stored credential hashes by issuing the `|rest` SPL command against the `/servicesNS/-/-/storage/passwords` endpoint, which incorrectly returns the `encr_password` field. Affected are Splunk Enterprise branches below 10.4.1, 10.2.5, 10.0.8, and 9.4.13, and multiple Splunk Cloud Platform versions. No public exploit has been identified at time of analysis and this CVE is not in CISA KEV, but the real-world impact is significant wherever Splunk stores credentials for external services such as databases, APIs, or cloud accounts.
Stored cross-site scripting in Splunk Enterprise (below 10.2.4, 10.0.7, 9.4.12, 9.3.13) and Splunk Cloud Platform (below 10.3.2512.11, 10.2.2510.15, 10.1.2507.23, 9.3.2411.132) allows a low-privileged authenticated user - without 'admin' or 'power' roles - to embed malicious JavaScript inside a classic dashboard HTML panel that executes in another user's browser session. Exploitation requires phishing the victim into initiating a specific browser request, and no public exploit was identified at time of analysis.
Classic dashboard style attribute injection in Splunk Enterprise and Splunk Cloud Platform enables a low-privileged authenticated user to craft panels that bypass the Trusted Domains List and exfiltrate sensitive data from a higher-privileged user's browser session. Affected branches span Splunk Enterprise below 10.2.4, 10.0.7, 9.4.12, and 9.3.13, and multiple Splunk Cloud Platform release trains. No public exploit has been identified at time of analysis, and SSVC rates current exploitation as none with partial technical impact, though the high confidentiality impact potential warrants prompt patching in environments where low-privileged users can share dashboards with administrators.
Improper access control on the saved search ownership reassignment endpoint in Splunk Enterprise and Splunk Cloud Platform allows a highly privileged authenticated user - one whose role contains the `edit_saved_search_owner` capability - to reassign saved search ownership to users outside their authorized scope. Affected versions span Splunk Enterprise below 10.2.4 and 10.0.7, and multiple Splunk Cloud Platform branches below their respective fixed builds. No public exploit has been identified at time of analysis, and the PR:H CVSS requirement confines risk primarily to insider threats or scenarios involving compromised privileged Splunk accounts.
Classic dashboard URL validation bypass in Splunk Enterprise and Splunk Cloud Platform enables low-privileged authenticated users to craft dashboards that silently exfiltrate sensitive data to attacker-controlled external servers. The flaw (CWE-20) resides in the external content dialog, which fails to enforce complete domain restrictions, allowing outbound requests to untrusted hosts when a victim interacts with the malicious dashboard. No public exploit exists and this vulnerability is not listed in CISA KEV, but the High confidentiality impact (C:H) in the CVSS vector reflects meaningful data exposure risk in environments where Splunk indexes security events, credentials, or sensitive operational logs.
CSS injection in Splunk Enterprise and Splunk Cloud Platform classic dashboards enables credential and sensitive data exfiltration by low-privileged users targeting higher-privileged accounts. A low-privileged user (without 'admin' or 'power' roles) can craft a malicious classic dashboard containing injected CSS via inline style attributes; when a higher-privileged user views the dashboard, outbound HTTP requests are triggered to attacker-controlled external servers, bypassing the Trusted Domains restriction. No public exploit has been identified at time of analysis and the vulnerability is not listed in the CISA KEV catalog, but the C:H confidentiality impact and cross-privilege exploitation path make this a meaningful insider or compromised-account threat in environments with mixed privilege levels.
Classic dashboard drill-down links in Splunk Enterprise and Splunk Cloud Platform can be weaponized by low-privileged authenticated users to silently redirect victims to attacker-controlled external sites, enabling data exfiltration. The flaw stems from an incomplete URL scheme validator that recognizes only 'http://' and 'https://' prefixes, allowing protocol-relative URLs like '//attacker.com' to bypass the external-navigation warning dialog entirely. No public exploit code exists and no active exploitation is confirmed (not in CISA KEV), but the attack requires only a low-privileged account and a single victim click, making it a realistic phishing vector in multi-tenant or large enterprise Splunk deployments.
Sensitive information disclosure in Splunk Enterprise (below 10.2.2 and 10.0.5) and Splunk Cloud Platform (multiple branches below 10.3.2512.8, 10.2.2510.11, 10.1.2507.21, and 10.0.2503.13) allows authenticated users with a role granting access to the `_internal` index to view session cookies and response bodies containing sensitive data logged by the platform. Cisco-reported and patched by Splunk in advisory SVD-2026-0503, the issue is a CWE-532 sensitive-data-in-logs flaw rather than a remote code execution bug, with no public exploit identified at time of analysis.
Denial of Service in Splunk Enterprise and Splunk Cloud Platform allows a low-privileged authenticated user to render the entire instance non-functional by exploiting missing input validation in the `coldToFrozen.sh` script bundled with the `splunk_archiver` app. The script accepts arbitrary file paths and renames them without restricting operations to safe directories, enabling renaming of critical Splunk system directories. No public exploit or CISA KEV listing has been identified at time of analysis, but the low privilege requirement (PR:L per CVSS) makes this actionable for any authenticated non-admin user in multi-tenant or enterprise deployments. A vendor patch is available via advisory SVD-2026-0504.
Improper access control in Splunk Enterprise
Account management inconsistencies in Splunk Enterprise and Splunk Cloud Platform allow users with the high-privilege 'edit_user' capability to create specially crafted usernames containing null bytes or non-UTF-8 percent-encoded bytes. This can lead to improper storage of usernames, resulting in inability to edit or delete affected users. No active exploitation has been identified and the EPSS score is very low (0.04%), indicating minimal real-world risk.