Splunk
Monthly
SQL injection in Splunk SOAR below version 8.6.0 enables users holding the "Automation Engineer" role to execute arbitrary SQL statements against the SOAR database by embedding injection payloads in custom list names referenced within playbooks, granting full create, read, update, and delete access to all data the database contains. The root cause is unsanitized string concatenation: Splunk SOAR builds the custom list lookup query by inserting the user-supplied list name directly rather than using parameterized (bound) values, a textbook CWE-74 injection pattern. No public exploit has been identified at time of analysis and the vulnerability is not in CISA KEV; vendor-released patch version 8.6.0 is available.
SQL injection in Splunk SOAR below version 8.6.0 enables authenticated users holding the "Automation Engineer" role to execute arbitrary SQL statements against the SOAR backend database by supplying crafted values through custom function results. The root cause (CWE-89) is Splunk SOAR concatenating the user-supplied name directly into the database lookup query rather than using parameterized, bound SQL values. Successful exploitation allows full read access to all data stored in the SOAR database - including playbook configurations, incident records, and integration credentials - and can affect database integrity; no public exploit or active exploitation (CISA KEV) has been identified at time of analysis.
SQL injection in Splunk SOAR's playbook automation data APIs grants any user holding the 'Automation Engineer' role unrestricted read, write, and delete access to the entire SOAR database in versions below 8.6.0. The vulnerability stems from user-supplied input being incorporated into database queries without proper sanitization (CWE-943), enabling arbitrary SQL execution against the SOAR backend. No public exploit code or active exploitation via CISA KEV has been identified at time of analysis; Splunk has released a patch in version 8.6.0.
Splunk SOAR versions below 8.6.0 contain a Server-Side Request Forgery flaw in the connectivity check REST API endpoint (/rest/support/connectivity/.../check_connectivity) that allows an authenticated Administrator-role user to direct the SOAR platform to initiate outbound network connections to arbitrary destinations. This enables internal network enumeration - discovering reachable hosts and open ports using the SOAR instance's network position, which is typically privileged within enterprise SOC environments. No public exploit code has been identified and the vulnerability is not listed in CISA KEV; the CVSS score of 2.7 (Low) accurately reflects the high privilege prerequisite, though the risk is elevated in environments where the SOAR platform has broad internal network access.
Unauthorized information disclosure in Splunk SOAR (On-premises) below version 8.6.0 exposes system health and cluster telemetry to any authenticated user, including those with no assigned role, via the /rest/health REST endpoint. The root cause is a missing authorization check (CWE-862) that validates session authentication but omits role-membership verification before returning restricted operational data. No active exploitation has been confirmed in CISA KEV, and no public exploit code has been identified; vendor patch is available in version 8.6.0 per advisory SVD-2026-0804.
Path traversal in Splunk SOAR's Universal Forwarder credentials-package extraction allows an authenticated Administrator to write files to arbitrary locations on the underlying host filesystem. Affecting all On-premises versions below 8.6.0, the flaw stems from the archive extraction workflow accepting member paths containing directory traversal sequences without first verifying each member's resolved destination. No public exploit or CISA KEV listing exists at time of analysis; however, the Integrity:High and Availability:High CVSS impact ratings indicate that a malicious archive could overwrite system-level files, enabling persistence or privilege escalation beyond SOAR's own permission boundary.
Path traversal during app installation in Splunk SOAR On-premises below version 8.6.0 allows an authenticated user holding app-install privileges to write files outside the intended temporary extraction directory. The archive extraction routine fails to validate that file paths within an uploaded archive remain within the designated staging directory, enabling a classic Zip Slip attack that can overwrite arbitrary files on the host. No public exploit has been identified at time of analysis, and exploitation is constrained by the high-privilege prerequisite (PR:H); a vendor-released patch is available in version 8.6.0.
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.
Draft release attachment disclosure in Gitea exposes files uploaded to draft releases to unauthenticated network callers via UUID-based web endpoints, bypassing access controls that correctly gate the parallel API handlers. This is an incomplete fix for CVE-2026-27660: that advisory's PR #36659 added `canAccessReleaseDraft` checks to every API code path but left the web-side `ServeAttachment` handler ungated, allowing anyone who obtains an attachment UUID to download its contents with no authentication. A working proof-of-concept is documented in the advisory and confirmed against Gitea v1.27.0+dev; no public exploit identified at time of analysis beyond the advisory PoC, and the vulnerability does not appear in CISA KEV.
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.
Outbound SSRF-class data exfiltration in Splunk AI Toolkit versions below 5.7.4 allows any low-privileged authenticated Splunk user - without admin or power roles - to redirect the AI agent's HTTP request mechanism to an attacker-controlled server. The root cause is an insecure default domain allowlist shipped with the toolkit that places no restrictions on which external domains the AI agent may contact. No public exploit code has been identified and this vulnerability is not listed in the CISA KEV catalog, but the low privilege barrier makes it broadly relevant in enterprise Splunk deployments with many standard users.
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.
ANSI escape code injection in Splunk SOAR versions below 8.5.0 allows an unauthenticated remote attacker to embed terminal control sequences into application log files via crafted HTTP request paths. When an administrator subsequently views those logs in a terminal emulator, the escape codes may be interpreted, enabling visual output manipulation such as overwriting displayed text, hiding log entries, or altering terminal state. No public exploit code has been identified at time of analysis, and exploitation requires administrator interaction with affected log output, keeping real-world risk moderate despite the low authentication barrier.
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.
Unauthorized data disclosure in Splunk AI Toolkit versions below 5.7.3 allows authenticated low-privileged users to bypass srchFilter-based access controls and read confidential data scoped to more restricted custom roles. The flaw stems from the Splunk platform's behavior of combining inherited search filters via the OR SPL operator, causing the permissive filter injected by the AI Toolkit's authorize.conf to override stricter filters on child roles. No active exploitation confirmed (not in CISA KEV) and no public exploit identified at time of analysis, but the CVSS confidentiality impact is rated High, making this a meaningful data exposure risk in multi-tenant or compliance-sensitive 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.
Path traversal in the CSV Export endpoint of ghantakiran's splunk-mcp-integration allows remote unauthenticated attackers to access arbitrary files on the server by manipulating the job_name parameter in the create_csv_export function. The vulnerability affects all versions up to commit 0b86b09d5e5adf0433acd43c975951224613a1a6, with publicly available exploit code disclosed via GitHub issue; no vendor patch has been released despite early notification.
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.
Improper access control in the Discover Splunk Observability Cloud app allows low-privileged users without admin or power roles to retrieve Observability Cloud API access tokens in Splunk Enterprise versions below 10.2.1/10.0.4 and Splunk Cloud Platform versions below 10.2.2510.5/10.1.2507.16/10.0.2503.12. An attacker with low-level credentials could leverage this to obtain API tokens for unauthorized access to Observability Cloud resources. No patch is currently available.
Improper access control in Splunk Enterprise and Cloud Platform versions below specified thresholds allows low-privileged users without admin or power roles to extract sensitive information from job search logs through the MongoClient logging channel. Affected versions include Enterprise 10.2.1, 10.0.4, 9.4.9, and 9.3.10, as well as corresponding Cloud Platform releases. No patch is currently available for this medium-severity vulnerability.
Splunk Enterprise and Cloud Platform versions below specified thresholds fail to properly restrict access to the passwords configuration API endpoint, allowing low-privileged users without admin or power roles to retrieve hashed or plaintext credential values from passwords.conf. This information disclosure vulnerability could enable attackers to obtain sensitive authentication credentials for further system compromise. No patch is currently available.
Stored XSS via path traversal in Splunk Enterprise and Cloud Platform allows low-privileged users to inject malicious JavaScript into Views, compromising any user who visits the affected page. An attacker must socially engineer a victim into initiating the malicious request, but no special privileges or user interaction beyond initial page load is required. Affected versions include Splunk Enterprise below 10.2.0, 10.0.3, 9.4.9, and 9.3.9, with no patch currently available.
Splunk Enterprise and Splunk Cloud Platform deployments expose SAML authentication configurations in plaintext logs accessible to users with Search Head Cluster administrative roles and _internal index access, allowing credential and authentication extension disclosure. Affected versions include Splunk Enterprise below 10.2.0, 10.0.2, 9.4.7, 9.3.8, and 9.2.11, as well as Splunk Cloud Platform versions below 10.2.2510.0, 10.1.2507.11, 10.0.2503.9, and 9.3.2411.120. No patch is currently available for this medium-severity vulnerability.
Splunk Enterprise versions before 10.2.0, 10.0.2, 9.4.7, 9.3.9, and 9.2.11 expose RSA access keys in plain text within the Authentication.conf file to users with access to the _internal index on Search Head Cluster deployments. A privileged user with appropriate role permissions could read these sensitive credentials, compromising authentication security. No patch is currently available for this medium-severity vulnerability.
Improper access control in Splunk Enterprise versions below 9.3.9, 9.4.8, and 10.0.2 allows low-privileged users without admin roles to access the Monitoring Console App endpoints, enabling unauthorized disclosure of sensitive information. The vulnerability affects only on-premises Splunk Enterprise deployments and does not impact Splunk Cloud Platform instances. No patch is currently available.
Client-side denial-of-service in Splunk Enterprise and Splunk Cloud Platform allows low-privileged users to inject malicious payloads through user profile parameters in the authentication REST API endpoint, causing significant page load delays or temporary unresponsiveness of the Splunk Web interface. Affected versions include Splunk Enterprise below 10.2.0, 10.0.2, 9.4.8, 9.3.9, and 9.2.12, and Splunk Cloud Platform below 10.2.2510.3, 10.1.2507.8, 10.0.2503.9, and 9.3.2411.121. No patch is currently available for this vulnerability.
Splunk Search Head Cluster deployments below versions 10.2.0, 10.0.2, 9.4.7, 9.3.9, and 9.2.11 expose Duo Two-Factor Authentication secrets (integrationKey, secretKey, appSecretKey) in plain text to users with access to the _internal index and appropriate roles. An authenticated attacker with these privileges could retrieve sensitive credentials and compromise Duo authentication controls for the Splunk environment. No patch is currently available for this vulnerability.
In Splunk Enterprise versions below 10.2.0, 10.0.3, 9.4.5, 9.3.7, and 9.2.9, and Splunk Cloud Platform versions below 10.1.2507.0, 10.0.2503.9, 9.3.2411.112, and 9.3.2408.122, a low-privileged user who does not hold the "admin" or "power" Splunk roles could bypass the SPL safeguards for risky commands when they create a Data Model that contains an injected SPL query within an object. [CVSS 3.5 LOW]
In Splunk Enterprise versions below 10.0.2, 9.4.6, 9.3.8, and 9.2.10, and versions below 3.9.10, 3.8.58 and 3.7.28 of the Splunk Secure Gateway app on Splunk Cloud Platform, a low-privileged user that does not hold the "admin" or "power" Splunk roles could craft a malicious payload through the `label` column field after adding a new device in the Splunk Secure Gateway app. This could potentially lead to a client-side denial of service (DoS).
In Splunk Enterprise versions below 10.0.1, 9.4.6, 9.3.8, and 9.2.10, and Splunk Cloud Platform versions below 10.1.2507.4, 10.0.2503.7, and 9.3.2411.116, a user who holds a role that contains the high privilege capability `change_authentication` could enumerate internal IP addresses and network ports when adding new search peers to a Splunk search head in a distributed environment.
In Splunk Universal Forwarder for Windows versions below 10.0.2, 9.4.6, 9.3.8, and 9.2.10, a new installation of or an upgrade to an affected version can result in incorrect permissions assignment in the Universal Forwarder for Windows Installation directory. This lets non-administrator users on the machine access the directory and all its contents.
In Splunk Enterprise for Windows versions below 10.0.2, 9.4.6, 9.3.8, and 9.2.10, a new installation of or an upgrade to an affected version can result in incorrect permissions assignment in the Splunk Enterprise for Windows Installation directory. This lets non-administrator users on the machine access the directory and all its contents.
In Splunk Enterprise versions below 10.0.2, 9.4.6, 9.3.8, and 9.2.10, and Splunk Cloud Platform versions below 10.1.2507.6, 10.0.2503.7, and 9.3.2411.117, a user who holds a role with a high privilege capability `admin_all_objects` could craft a malicious payload through the href attribute of an anchor tag within a collection in the navigation bar, which could result in execution of unauthorized JavaScript code in the browser of a user.
A security vulnerability in Splunk Enterprise (CVSS 5.3) that allows them. Remediation should follow standard vulnerability management procedures.
In Splunk Enterprise versions below 10.0.2, 9.4.6, 9.3.8, and 9.2.10, and below 3.9.10, 3.8.58, and 3.7.28 of Splunk Secure Gateway app in Splunk Cloud Platform, a low-privileged user that does not hold the "admin" or "power" Splunk roles and subscribes to mobile push notifications could receive notifications that disclose the title and description of the report or alert even if they do not have access to view the report or alert.
In Splunk Enterprise versions below 10.0.2, 9.4.6, 9.3.8, and 9.2.10, and Splunk Cloud Platform versions below 10.1.2507.10, 10.0.2503.8, and 9.3.2411.120, a low-privileged user that does not hold the "admin" or "power" Splunk roles could create a views dashboard with a custom background using the `data:image/png;base64` protocol that could potentially lead to an unvalidated redirect. This behavior circumvents the Splunk external URL warning mechanism by using a specially crafted URL, allowing for a redirection to an external malicious site. The vulnerability requires the attacker to phish the victim by tricking them into initiating a request within their browser. The authenticated user should not be able to exploit the vulnerability at will.
In Splunk Enterprise versions below 10.0.1, 9.4.5, 9.3.7, and 9.2.9 and Splunk Cloud Platform versions below 9.3.2411.116, 9.3.2408.124, 10.0.2503.5 and 10.1.2507.1, a low-privileged user that does. Rated low severity (CVSS 3.5), this vulnerability is remotely exploitable, low attack complexity. No vendor patch available.
In Splunk Enterprise versions below 10.0.1, 9.4.5, 9.3.7, 9.2.9, and Splunk Cloud Platform versions below 10.0.2503.5, 9.3.2411.111, and 9.3.2408.121, an unauthenticated attacker could craft a. Rated low severity (CVSS 3.1), this vulnerability is remotely exploitable, no authentication required. No vendor patch available.
In Splunk Enterprise versions below 10.0.1, 9.4.4, 9.3.6 and 9.2.8, and Splunk Cloud Platform versions below 9.3.2411.109, 9.3.2408.119 and 9.2.2406.122, an unauthenticated attacker could trigger a blind server-side request forgery (SSRF) potentially letting an attacker perform REST API calls on behalf of an authenticated high-privileged user.
In Splunk Enterprise versions below 10.0.1, 9.4.4, 9.3.6, and 9.2.8, and Splunk Cloud Platform versions below 9.3.2411.108, 9.3.2408.118 and 9.2.2406.123, a user who holds a role that contains the high-privilege capability `change_authentication`, could send multiple LDAP bind requests to a specific internal endpoint, resulting in high server CPU usage, which could potentially lead to a denial of service (DoS) until the Splunk Enterprise instance is restarted. See https://help.splunk.com/en/splunk-enterprise/administer/manage-users-and-security/10.0/manage-splunk-platform-users-and-roles/define-roles-on-the-splunk-platform-with-capabilities and https://help.splunk.com/en/splunk-enterprise/administer/manage-users-and-security/10.0/use-ldap-as-an-authentication-scheme/configure-ldap-with-splunk-web#cfe47e31_007f_460d_8b3d_8505ffc3f0dd__Configure_LDAP_with_Splunk_Web for more information.
In Splunk Enterprise versions below 9.4.4, 9.3.6, and 9.2.8, and Splunk Cloud Platform versions below 9.3.2411.108, 9.3.2408.118 and 9.2.2406.123, a low privilege user that does not hold the "admin" or "power" Splunk roles could perform an extensible markup language (XML) external entity (XXE) injection through the dashboard tab label field. The XXE injection has the potential to cause denial of service (DoS) attacks.
In Splunk Enterprise versions below 9.4.4, 9.3.6, and 9.2.8, and Splunk Cloud Platform versions below 9.3.2411.108, 9.3.2408.118 and 9.2.2406.123, a low privileged user that does not hold the admin or power Splunk roles could craft a malicious payload through the error messages and job inspection details of a saved search. This could result in execution of unauthorized JavaScript code in the browser of a user.
In Splunk Enterprise versions below 9.4.4, 9.3.6 and 9.2.8, and Splunk Cloud Platform versions below 9.3.2411.109, 9.3.2408.119 and 9.2.2406.122, a low-privileged user that does not hold the 'admin' or 'power' Splunk roles could craft a malicious payload through the `dataset.command` parameter of the `/app/search/table` endpoint, which could result in execution of unauthorized JavaScript code in the browser of a user.
In Splunk Enterprise versions below 9.4.4, 9.3.6, and 9.2.8, and Splunk Cloud Platform versions below 9.3.2411.111, 9.3.2408.119, and 9.2.2406.122, a low-privileged user that does not hold the admin or power Splunk roles could access sensitive search results if Splunk Enterprise runs an administrative search job in the background. If the low privileged user guesses the search job’s unique Search ID (SID), the user could retrieve the results of that job, potentially exposing sensitive search results. For more information see https://help.splunk.com/en/splunk-enterprise/search/search-manual/10.0/manage-jobs/about-jobs-and-job-management and https://help.splunk.com/en/splunk-enterprise/search/search-manual/10.0/manage-jobs/manage-search-jobs.
In Splunk Enterprise versions below 9.4.3, 9.3.5, 9.2.7, and 9.1.10, and Splunk Cloud Platform versions below 9.3.2411.103, 9.3.2408.113, and 9.2.2406.119, the software potentially exposes the search head cluster [splunk.secret](https://help.splunk.com/en/splunk-enterprise/administer/manage-users-and-security/9.4/install-splunk-enterprise-securely/deploy-secure-passwords-across-multiple-servers) key. This exposure could happen if you have a Search Head cluster and you configure the Splunk Enterprise `SHCConfig` log channel at the DEBUG logging level in the clustered deployment. <br><br>The vulnerability would require either local access to the log files or administrative access to internal indexes, which by default only the admin role receives. Review roles and capabilities on your instance and restrict internal index access to administrator-level roles. <br><br>See [Define roles on the Splunk platform with capabilities](https://docs.splunk.com/Documentation/Splunk/latest/Security/Rolesandcapabilities), [Deploy a search head cluster](https://help.splunk.com/en/splunk-enterprise/administer/distributed-search/9.4/deploy-search-head-clustering/deploy-a-search-head-cluster), [Deploy secure passwords across multiple servers](https://help.splunk.com/en/splunk-enterprise/administer/manage-users-and-security/9.4/install-splunk-enterprise-securely/deploy-secure-passwords-across-multiple-servers) and [Set a security key for the search head cluster](https://help.splunk.com/splunk-enterprise/administer/distributed-search/9.4/configure-search-head-clustering/set-a-security-key-for-the-search-head-cluster#id_2c54937a_736c_47b5_9485_67e9e390acfa__Set_a_security_key_for_the_search_head_cluster) for more information.
In Splunk Enterprise versions below 9.4.2, 9.3.5, 9.2.7, and 9.1.10 and Splunk Cloud Platform versions below 9.3.2411.104, 9.3.2408.113, and 9.2.2406.119, a low-privileged user that does not hold the "admin" or "power" Splunk roles could create or overwrite [system source type](https://help.splunk.com/en/splunk-enterprise/get-started/get-data-in/9.2/configure-source-types/create-source-types) configurations by sending a specially-crafted payload to the `/servicesNS/nobody/search/admin/sourcetypes/` REST endpoint on the Splunk management port.
In Splunk Enterprise versions below 9.4.3, 9.3.5, 9.2.7, and 9.1.10, a low-privileged user that does not hold the "admin" or "power" Splunk roles could turn off the scheduled search `Bucket Copy Trigger` within the Splunk Archiver application. This is because of missing access controls in the saved searches for this app.
In Splunk Enterprise versions below 9.4.3, 9.3.5, 9.2.7, and 9.1.10, and Splunk Cloud Platform versions below 9.3.2411.104, 9.3.2408.113, and 9.2.2406.119, an unauthenticated attacker could send a specially-crafted SPL search command that could trigger a rolling restart in the Search Head Cluster through a Cross-Site Request Forgery (CSRF), potentially leading to a denial of service (DoS).<br><br>The vulnerability requires the attacker to phish the administrator-level victim by tricking them into initiating a request within their browser. The attacker should not be able to exploit the vulnerability at will.<br><br>See [How rolling restart works](https://docs.splunk.com/Documentation/Splunk/9.4.2/DistSearch/RestartSHC) for more information.
In Splunk Enterprise versions below 9.4.3, 9.3.5, 9.2.7 and 9.1.10, and Splunk Cloud Platform versions below 9.3.2411.104, 9.3.2408.114, and 9.2.2406.119, an unauthenticated attacker can send a specially-crafted SPL search that could change the membership state in a Splunk Search Head Cluster (SHC) through a Cross-Site Request Forgery (CSRF), potentially leading to the removal of the captain or a member of the SHC.<br><br>The vulnerability requires the attacker to phish the administrator-level victim by tricking them into initiating a request within their browser. The attacker should not be able to exploit the vulnerability at will.
In Splunk Enterprise versions below 9.4.3, 9.3.5, 9.2.7 and 9.1.10, and Splunk Cloud Platform versions below 9.3.2411.107, 9.3.2408.117, and 9.2.2406.121, a low-privileged user that does not hold the "admin" or "power" Splunk roles could craft a malicious payload through the `User Interface - Views` configuration page that could potentially lead to a denial of service (DoS).The user could cause the DoS by exploiting a path traversal vulnerability that allows for deletion of arbitrary files within a Splunk directory. The vulnerability requires the low-privileged user to phish the administrator-level victim by tricking them into initiating a request within their browser. The low-privileged user should not be able to exploit the vulnerability at will.
In Splunk Enterprise versions below 9.4.3, 9.3.5, 9.2.7, and 9.1.10, a user who holds a role that contains the high-privilege capability `edit_scripted` and `list_inputs` capability , could perform a remote command execution due to improper user input sanitization on the scripted input files.<br><br>See [Define roles on the Splunk platform with capabilities](https://docs.splunk.com/Documentation/Splunk/latest/Security/Rolesandcapabilities) and [Setting up a scripted input ](https://docs.splunk.com/Documentation/Splunk/9.4.2/AdvancedDev/ScriptSetup)for more information.
In Splunk Enterprise versions below 9.4.2, 9.3.5, 9.2.6, and 9.1.9 and Splunk Cloud Platform versions below 9.3.2411.103, 9.3.2408.112, and 9.2.2406.119, a low-privileged user that does not hold the "admin" or "power" Splunk roles, and has read-only access to a specific alert, could suppress that alert when it triggers. See [Define alert suppression groups to throttle sets of similar alerts](https://help.splunk.com/en/splunk-enterprise/alert-and-respond/alerting-manual/9.4/manage-alert-trigger-conditions-and-throttling/define-alert-suppression-groups-to-throttle-sets-of-similar-alerts).
Privilege escalation vulnerability in Splunk Universal Forwarder for Windows where incorrect file system permissions are assigned during installation or upgrade, allowing non-administrator users to read and modify sensitive files in the installation directory. This affects versions below 9.4.2, 9.3.4, 9.2.6, and 9.1.9, and could enable unauthorized access to credentials, configuration files, and system monitoring data. While CVSS 8.0 indicates high severity, real-world exploitation requires local access and user interaction (UI requirement per vector), limiting attack scope.
In Splunk Enterprise versions below 9.4.2, 9.3.4 and 9.2.6, and Splunk Cloud Platform versions below 9.3.2411.102, 9.3.2408.111 and 9.2.2406.118, a low-privileged user that does not hold the "admin" or "power" Splunk roles could craft a malicious payload through the pdfgen/render REST endpoint that could result in execution of unauthorized JavaScript code in the browser of a user.
In Splunk Enterprise versions below 9.4.1, 9.3.3, 9.2.5, and 9.1.8, and versions below 3.8.38 and 3.7.23 of the Splunk Secure Gateway app on Splunk Cloud Platform, a low-privileged user that does not. Rated medium severity (CVSS 4.3), this vulnerability is remotely exploitable, low attack complexity. No vendor patch available.
In the Splunk App for Lookup File Editing versions below 4.0.5, a script in the app used the `chmod` and `makedirs` Python functions in a way that resulted in overly broad read and execute. Rated low severity (CVSS 2.5). No vendor patch available.
In Splunk Enterprise versions below 9.3.3, 9.2.5, and 9.1.8 and Splunk Cloud Platform versions below 9.3.2408.103, 9.2.2406.108, 9.2.2403.113, 9.1.2312.208 and 9.1.2308.212, a low-privileged user. Rated medium severity (CVSS 5.7), this vulnerability is remotely exploitable, low attack complexity. No vendor patch available.
SQL injection in Splunk SOAR below version 8.6.0 enables users holding the "Automation Engineer" role to execute arbitrary SQL statements against the SOAR database by embedding injection payloads in custom list names referenced within playbooks, granting full create, read, update, and delete access to all data the database contains. The root cause is unsanitized string concatenation: Splunk SOAR builds the custom list lookup query by inserting the user-supplied list name directly rather than using parameterized (bound) values, a textbook CWE-74 injection pattern. No public exploit has been identified at time of analysis and the vulnerability is not in CISA KEV; vendor-released patch version 8.6.0 is available.
SQL injection in Splunk SOAR below version 8.6.0 enables authenticated users holding the "Automation Engineer" role to execute arbitrary SQL statements against the SOAR backend database by supplying crafted values through custom function results. The root cause (CWE-89) is Splunk SOAR concatenating the user-supplied name directly into the database lookup query rather than using parameterized, bound SQL values. Successful exploitation allows full read access to all data stored in the SOAR database - including playbook configurations, incident records, and integration credentials - and can affect database integrity; no public exploit or active exploitation (CISA KEV) has been identified at time of analysis.
SQL injection in Splunk SOAR's playbook automation data APIs grants any user holding the 'Automation Engineer' role unrestricted read, write, and delete access to the entire SOAR database in versions below 8.6.0. The vulnerability stems from user-supplied input being incorporated into database queries without proper sanitization (CWE-943), enabling arbitrary SQL execution against the SOAR backend. No public exploit code or active exploitation via CISA KEV has been identified at time of analysis; Splunk has released a patch in version 8.6.0.
Splunk SOAR versions below 8.6.0 contain a Server-Side Request Forgery flaw in the connectivity check REST API endpoint (/rest/support/connectivity/.../check_connectivity) that allows an authenticated Administrator-role user to direct the SOAR platform to initiate outbound network connections to arbitrary destinations. This enables internal network enumeration - discovering reachable hosts and open ports using the SOAR instance's network position, which is typically privileged within enterprise SOC environments. No public exploit code has been identified and the vulnerability is not listed in CISA KEV; the CVSS score of 2.7 (Low) accurately reflects the high privilege prerequisite, though the risk is elevated in environments where the SOAR platform has broad internal network access.
Unauthorized information disclosure in Splunk SOAR (On-premises) below version 8.6.0 exposes system health and cluster telemetry to any authenticated user, including those with no assigned role, via the /rest/health REST endpoint. The root cause is a missing authorization check (CWE-862) that validates session authentication but omits role-membership verification before returning restricted operational data. No active exploitation has been confirmed in CISA KEV, and no public exploit code has been identified; vendor patch is available in version 8.6.0 per advisory SVD-2026-0804.
Path traversal in Splunk SOAR's Universal Forwarder credentials-package extraction allows an authenticated Administrator to write files to arbitrary locations on the underlying host filesystem. Affecting all On-premises versions below 8.6.0, the flaw stems from the archive extraction workflow accepting member paths containing directory traversal sequences without first verifying each member's resolved destination. No public exploit or CISA KEV listing exists at time of analysis; however, the Integrity:High and Availability:High CVSS impact ratings indicate that a malicious archive could overwrite system-level files, enabling persistence or privilege escalation beyond SOAR's own permission boundary.
Path traversal during app installation in Splunk SOAR On-premises below version 8.6.0 allows an authenticated user holding app-install privileges to write files outside the intended temporary extraction directory. The archive extraction routine fails to validate that file paths within an uploaded archive remain within the designated staging directory, enabling a classic Zip Slip attack that can overwrite arbitrary files on the host. No public exploit has been identified at time of analysis, and exploitation is constrained by the high-privilege prerequisite (PR:H); a vendor-released patch is available in version 8.6.0.
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.
Draft release attachment disclosure in Gitea exposes files uploaded to draft releases to unauthenticated network callers via UUID-based web endpoints, bypassing access controls that correctly gate the parallel API handlers. This is an incomplete fix for CVE-2026-27660: that advisory's PR #36659 added `canAccessReleaseDraft` checks to every API code path but left the web-side `ServeAttachment` handler ungated, allowing anyone who obtains an attachment UUID to download its contents with no authentication. A working proof-of-concept is documented in the advisory and confirmed against Gitea v1.27.0+dev; no public exploit identified at time of analysis beyond the advisory PoC, and the vulnerability does not appear in CISA KEV.
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.
Outbound SSRF-class data exfiltration in Splunk AI Toolkit versions below 5.7.4 allows any low-privileged authenticated Splunk user - without admin or power roles - to redirect the AI agent's HTTP request mechanism to an attacker-controlled server. The root cause is an insecure default domain allowlist shipped with the toolkit that places no restrictions on which external domains the AI agent may contact. No public exploit code has been identified and this vulnerability is not listed in the CISA KEV catalog, but the low privilege barrier makes it broadly relevant in enterprise Splunk deployments with many standard users.
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.
ANSI escape code injection in Splunk SOAR versions below 8.5.0 allows an unauthenticated remote attacker to embed terminal control sequences into application log files via crafted HTTP request paths. When an administrator subsequently views those logs in a terminal emulator, the escape codes may be interpreted, enabling visual output manipulation such as overwriting displayed text, hiding log entries, or altering terminal state. No public exploit code has been identified at time of analysis, and exploitation requires administrator interaction with affected log output, keeping real-world risk moderate despite the low authentication barrier.
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.
Unauthorized data disclosure in Splunk AI Toolkit versions below 5.7.3 allows authenticated low-privileged users to bypass srchFilter-based access controls and read confidential data scoped to more restricted custom roles. The flaw stems from the Splunk platform's behavior of combining inherited search filters via the OR SPL operator, causing the permissive filter injected by the AI Toolkit's authorize.conf to override stricter filters on child roles. No active exploitation confirmed (not in CISA KEV) and no public exploit identified at time of analysis, but the CVSS confidentiality impact is rated High, making this a meaningful data exposure risk in multi-tenant or compliance-sensitive 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.
Path traversal in the CSV Export endpoint of ghantakiran's splunk-mcp-integration allows remote unauthenticated attackers to access arbitrary files on the server by manipulating the job_name parameter in the create_csv_export function. The vulnerability affects all versions up to commit 0b86b09d5e5adf0433acd43c975951224613a1a6, with publicly available exploit code disclosed via GitHub issue; no vendor patch has been released despite early notification.
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.
Improper access control in the Discover Splunk Observability Cloud app allows low-privileged users without admin or power roles to retrieve Observability Cloud API access tokens in Splunk Enterprise versions below 10.2.1/10.0.4 and Splunk Cloud Platform versions below 10.2.2510.5/10.1.2507.16/10.0.2503.12. An attacker with low-level credentials could leverage this to obtain API tokens for unauthorized access to Observability Cloud resources. No patch is currently available.
Improper access control in Splunk Enterprise and Cloud Platform versions below specified thresholds allows low-privileged users without admin or power roles to extract sensitive information from job search logs through the MongoClient logging channel. Affected versions include Enterprise 10.2.1, 10.0.4, 9.4.9, and 9.3.10, as well as corresponding Cloud Platform releases. No patch is currently available for this medium-severity vulnerability.
Splunk Enterprise and Cloud Platform versions below specified thresholds fail to properly restrict access to the passwords configuration API endpoint, allowing low-privileged users without admin or power roles to retrieve hashed or plaintext credential values from passwords.conf. This information disclosure vulnerability could enable attackers to obtain sensitive authentication credentials for further system compromise. No patch is currently available.
Stored XSS via path traversal in Splunk Enterprise and Cloud Platform allows low-privileged users to inject malicious JavaScript into Views, compromising any user who visits the affected page. An attacker must socially engineer a victim into initiating the malicious request, but no special privileges or user interaction beyond initial page load is required. Affected versions include Splunk Enterprise below 10.2.0, 10.0.3, 9.4.9, and 9.3.9, with no patch currently available.
Splunk Enterprise and Splunk Cloud Platform deployments expose SAML authentication configurations in plaintext logs accessible to users with Search Head Cluster administrative roles and _internal index access, allowing credential and authentication extension disclosure. Affected versions include Splunk Enterprise below 10.2.0, 10.0.2, 9.4.7, 9.3.8, and 9.2.11, as well as Splunk Cloud Platform versions below 10.2.2510.0, 10.1.2507.11, 10.0.2503.9, and 9.3.2411.120. No patch is currently available for this medium-severity vulnerability.
Splunk Enterprise versions before 10.2.0, 10.0.2, 9.4.7, 9.3.9, and 9.2.11 expose RSA access keys in plain text within the Authentication.conf file to users with access to the _internal index on Search Head Cluster deployments. A privileged user with appropriate role permissions could read these sensitive credentials, compromising authentication security. No patch is currently available for this medium-severity vulnerability.
Improper access control in Splunk Enterprise versions below 9.3.9, 9.4.8, and 10.0.2 allows low-privileged users without admin roles to access the Monitoring Console App endpoints, enabling unauthorized disclosure of sensitive information. The vulnerability affects only on-premises Splunk Enterprise deployments and does not impact Splunk Cloud Platform instances. No patch is currently available.
Client-side denial-of-service in Splunk Enterprise and Splunk Cloud Platform allows low-privileged users to inject malicious payloads through user profile parameters in the authentication REST API endpoint, causing significant page load delays or temporary unresponsiveness of the Splunk Web interface. Affected versions include Splunk Enterprise below 10.2.0, 10.0.2, 9.4.8, 9.3.9, and 9.2.12, and Splunk Cloud Platform below 10.2.2510.3, 10.1.2507.8, 10.0.2503.9, and 9.3.2411.121. No patch is currently available for this vulnerability.
Splunk Search Head Cluster deployments below versions 10.2.0, 10.0.2, 9.4.7, 9.3.9, and 9.2.11 expose Duo Two-Factor Authentication secrets (integrationKey, secretKey, appSecretKey) in plain text to users with access to the _internal index and appropriate roles. An authenticated attacker with these privileges could retrieve sensitive credentials and compromise Duo authentication controls for the Splunk environment. No patch is currently available for this vulnerability.
In Splunk Enterprise versions below 10.2.0, 10.0.3, 9.4.5, 9.3.7, and 9.2.9, and Splunk Cloud Platform versions below 10.1.2507.0, 10.0.2503.9, 9.3.2411.112, and 9.3.2408.122, a low-privileged user who does not hold the "admin" or "power" Splunk roles could bypass the SPL safeguards for risky commands when they create a Data Model that contains an injected SPL query within an object. [CVSS 3.5 LOW]
In Splunk Enterprise versions below 10.0.2, 9.4.6, 9.3.8, and 9.2.10, and versions below 3.9.10, 3.8.58 and 3.7.28 of the Splunk Secure Gateway app on Splunk Cloud Platform, a low-privileged user that does not hold the "admin" or "power" Splunk roles could craft a malicious payload through the `label` column field after adding a new device in the Splunk Secure Gateway app. This could potentially lead to a client-side denial of service (DoS).
In Splunk Enterprise versions below 10.0.1, 9.4.6, 9.3.8, and 9.2.10, and Splunk Cloud Platform versions below 10.1.2507.4, 10.0.2503.7, and 9.3.2411.116, a user who holds a role that contains the high privilege capability `change_authentication` could enumerate internal IP addresses and network ports when adding new search peers to a Splunk search head in a distributed environment.
In Splunk Universal Forwarder for Windows versions below 10.0.2, 9.4.6, 9.3.8, and 9.2.10, a new installation of or an upgrade to an affected version can result in incorrect permissions assignment in the Universal Forwarder for Windows Installation directory. This lets non-administrator users on the machine access the directory and all its contents.
In Splunk Enterprise for Windows versions below 10.0.2, 9.4.6, 9.3.8, and 9.2.10, a new installation of or an upgrade to an affected version can result in incorrect permissions assignment in the Splunk Enterprise for Windows Installation directory. This lets non-administrator users on the machine access the directory and all its contents.
In Splunk Enterprise versions below 10.0.2, 9.4.6, 9.3.8, and 9.2.10, and Splunk Cloud Platform versions below 10.1.2507.6, 10.0.2503.7, and 9.3.2411.117, a user who holds a role with a high privilege capability `admin_all_objects` could craft a malicious payload through the href attribute of an anchor tag within a collection in the navigation bar, which could result in execution of unauthorized JavaScript code in the browser of a user.
A security vulnerability in Splunk Enterprise (CVSS 5.3) that allows them. Remediation should follow standard vulnerability management procedures.
In Splunk Enterprise versions below 10.0.2, 9.4.6, 9.3.8, and 9.2.10, and below 3.9.10, 3.8.58, and 3.7.28 of Splunk Secure Gateway app in Splunk Cloud Platform, a low-privileged user that does not hold the "admin" or "power" Splunk roles and subscribes to mobile push notifications could receive notifications that disclose the title and description of the report or alert even if they do not have access to view the report or alert.
In Splunk Enterprise versions below 10.0.2, 9.4.6, 9.3.8, and 9.2.10, and Splunk Cloud Platform versions below 10.1.2507.10, 10.0.2503.8, and 9.3.2411.120, a low-privileged user that does not hold the "admin" or "power" Splunk roles could create a views dashboard with a custom background using the `data:image/png;base64` protocol that could potentially lead to an unvalidated redirect. This behavior circumvents the Splunk external URL warning mechanism by using a specially crafted URL, allowing for a redirection to an external malicious site. The vulnerability requires the attacker to phish the victim by tricking them into initiating a request within their browser. The authenticated user should not be able to exploit the vulnerability at will.
In Splunk Enterprise versions below 10.0.1, 9.4.5, 9.3.7, and 9.2.9 and Splunk Cloud Platform versions below 9.3.2411.116, 9.3.2408.124, 10.0.2503.5 and 10.1.2507.1, a low-privileged user that does. Rated low severity (CVSS 3.5), this vulnerability is remotely exploitable, low attack complexity. No vendor patch available.
In Splunk Enterprise versions below 10.0.1, 9.4.5, 9.3.7, 9.2.9, and Splunk Cloud Platform versions below 10.0.2503.5, 9.3.2411.111, and 9.3.2408.121, an unauthenticated attacker could craft a. Rated low severity (CVSS 3.1), this vulnerability is remotely exploitable, no authentication required. No vendor patch available.
In Splunk Enterprise versions below 10.0.1, 9.4.4, 9.3.6 and 9.2.8, and Splunk Cloud Platform versions below 9.3.2411.109, 9.3.2408.119 and 9.2.2406.122, an unauthenticated attacker could trigger a blind server-side request forgery (SSRF) potentially letting an attacker perform REST API calls on behalf of an authenticated high-privileged user.
In Splunk Enterprise versions below 10.0.1, 9.4.4, 9.3.6, and 9.2.8, and Splunk Cloud Platform versions below 9.3.2411.108, 9.3.2408.118 and 9.2.2406.123, a user who holds a role that contains the high-privilege capability `change_authentication`, could send multiple LDAP bind requests to a specific internal endpoint, resulting in high server CPU usage, which could potentially lead to a denial of service (DoS) until the Splunk Enterprise instance is restarted. See https://help.splunk.com/en/splunk-enterprise/administer/manage-users-and-security/10.0/manage-splunk-platform-users-and-roles/define-roles-on-the-splunk-platform-with-capabilities and https://help.splunk.com/en/splunk-enterprise/administer/manage-users-and-security/10.0/use-ldap-as-an-authentication-scheme/configure-ldap-with-splunk-web#cfe47e31_007f_460d_8b3d_8505ffc3f0dd__Configure_LDAP_with_Splunk_Web for more information.
In Splunk Enterprise versions below 9.4.4, 9.3.6, and 9.2.8, and Splunk Cloud Platform versions below 9.3.2411.108, 9.3.2408.118 and 9.2.2406.123, a low privilege user that does not hold the "admin" or "power" Splunk roles could perform an extensible markup language (XML) external entity (XXE) injection through the dashboard tab label field. The XXE injection has the potential to cause denial of service (DoS) attacks.
In Splunk Enterprise versions below 9.4.4, 9.3.6, and 9.2.8, and Splunk Cloud Platform versions below 9.3.2411.108, 9.3.2408.118 and 9.2.2406.123, a low privileged user that does not hold the admin or power Splunk roles could craft a malicious payload through the error messages and job inspection details of a saved search. This could result in execution of unauthorized JavaScript code in the browser of a user.
In Splunk Enterprise versions below 9.4.4, 9.3.6 and 9.2.8, and Splunk Cloud Platform versions below 9.3.2411.109, 9.3.2408.119 and 9.2.2406.122, a low-privileged user that does not hold the 'admin' or 'power' Splunk roles could craft a malicious payload through the `dataset.command` parameter of the `/app/search/table` endpoint, which could result in execution of unauthorized JavaScript code in the browser of a user.
In Splunk Enterprise versions below 9.4.4, 9.3.6, and 9.2.8, and Splunk Cloud Platform versions below 9.3.2411.111, 9.3.2408.119, and 9.2.2406.122, a low-privileged user that does not hold the admin or power Splunk roles could access sensitive search results if Splunk Enterprise runs an administrative search job in the background. If the low privileged user guesses the search job’s unique Search ID (SID), the user could retrieve the results of that job, potentially exposing sensitive search results. For more information see https://help.splunk.com/en/splunk-enterprise/search/search-manual/10.0/manage-jobs/about-jobs-and-job-management and https://help.splunk.com/en/splunk-enterprise/search/search-manual/10.0/manage-jobs/manage-search-jobs.
In Splunk Enterprise versions below 9.4.3, 9.3.5, 9.2.7, and 9.1.10, and Splunk Cloud Platform versions below 9.3.2411.103, 9.3.2408.113, and 9.2.2406.119, the software potentially exposes the search head cluster [splunk.secret](https://help.splunk.com/en/splunk-enterprise/administer/manage-users-and-security/9.4/install-splunk-enterprise-securely/deploy-secure-passwords-across-multiple-servers) key. This exposure could happen if you have a Search Head cluster and you configure the Splunk Enterprise `SHCConfig` log channel at the DEBUG logging level in the clustered deployment. <br><br>The vulnerability would require either local access to the log files or administrative access to internal indexes, which by default only the admin role receives. Review roles and capabilities on your instance and restrict internal index access to administrator-level roles. <br><br>See [Define roles on the Splunk platform with capabilities](https://docs.splunk.com/Documentation/Splunk/latest/Security/Rolesandcapabilities), [Deploy a search head cluster](https://help.splunk.com/en/splunk-enterprise/administer/distributed-search/9.4/deploy-search-head-clustering/deploy-a-search-head-cluster), [Deploy secure passwords across multiple servers](https://help.splunk.com/en/splunk-enterprise/administer/manage-users-and-security/9.4/install-splunk-enterprise-securely/deploy-secure-passwords-across-multiple-servers) and [Set a security key for the search head cluster](https://help.splunk.com/splunk-enterprise/administer/distributed-search/9.4/configure-search-head-clustering/set-a-security-key-for-the-search-head-cluster#id_2c54937a_736c_47b5_9485_67e9e390acfa__Set_a_security_key_for_the_search_head_cluster) for more information.
In Splunk Enterprise versions below 9.4.2, 9.3.5, 9.2.7, and 9.1.10 and Splunk Cloud Platform versions below 9.3.2411.104, 9.3.2408.113, and 9.2.2406.119, a low-privileged user that does not hold the "admin" or "power" Splunk roles could create or overwrite [system source type](https://help.splunk.com/en/splunk-enterprise/get-started/get-data-in/9.2/configure-source-types/create-source-types) configurations by sending a specially-crafted payload to the `/servicesNS/nobody/search/admin/sourcetypes/` REST endpoint on the Splunk management port.
In Splunk Enterprise versions below 9.4.3, 9.3.5, 9.2.7, and 9.1.10, a low-privileged user that does not hold the "admin" or "power" Splunk roles could turn off the scheduled search `Bucket Copy Trigger` within the Splunk Archiver application. This is because of missing access controls in the saved searches for this app.
In Splunk Enterprise versions below 9.4.3, 9.3.5, 9.2.7, and 9.1.10, and Splunk Cloud Platform versions below 9.3.2411.104, 9.3.2408.113, and 9.2.2406.119, an unauthenticated attacker could send a specially-crafted SPL search command that could trigger a rolling restart in the Search Head Cluster through a Cross-Site Request Forgery (CSRF), potentially leading to a denial of service (DoS).<br><br>The vulnerability requires the attacker to phish the administrator-level victim by tricking them into initiating a request within their browser. The attacker should not be able to exploit the vulnerability at will.<br><br>See [How rolling restart works](https://docs.splunk.com/Documentation/Splunk/9.4.2/DistSearch/RestartSHC) for more information.
In Splunk Enterprise versions below 9.4.3, 9.3.5, 9.2.7 and 9.1.10, and Splunk Cloud Platform versions below 9.3.2411.104, 9.3.2408.114, and 9.2.2406.119, an unauthenticated attacker can send a specially-crafted SPL search that could change the membership state in a Splunk Search Head Cluster (SHC) through a Cross-Site Request Forgery (CSRF), potentially leading to the removal of the captain or a member of the SHC.<br><br>The vulnerability requires the attacker to phish the administrator-level victim by tricking them into initiating a request within their browser. The attacker should not be able to exploit the vulnerability at will.
In Splunk Enterprise versions below 9.4.3, 9.3.5, 9.2.7 and 9.1.10, and Splunk Cloud Platform versions below 9.3.2411.107, 9.3.2408.117, and 9.2.2406.121, a low-privileged user that does not hold the "admin" or "power" Splunk roles could craft a malicious payload through the `User Interface - Views` configuration page that could potentially lead to a denial of service (DoS).The user could cause the DoS by exploiting a path traversal vulnerability that allows for deletion of arbitrary files within a Splunk directory. The vulnerability requires the low-privileged user to phish the administrator-level victim by tricking them into initiating a request within their browser. The low-privileged user should not be able to exploit the vulnerability at will.
In Splunk Enterprise versions below 9.4.3, 9.3.5, 9.2.7, and 9.1.10, a user who holds a role that contains the high-privilege capability `edit_scripted` and `list_inputs` capability , could perform a remote command execution due to improper user input sanitization on the scripted input files.<br><br>See [Define roles on the Splunk platform with capabilities](https://docs.splunk.com/Documentation/Splunk/latest/Security/Rolesandcapabilities) and [Setting up a scripted input ](https://docs.splunk.com/Documentation/Splunk/9.4.2/AdvancedDev/ScriptSetup)for more information.
In Splunk Enterprise versions below 9.4.2, 9.3.5, 9.2.6, and 9.1.9 and Splunk Cloud Platform versions below 9.3.2411.103, 9.3.2408.112, and 9.2.2406.119, a low-privileged user that does not hold the "admin" or "power" Splunk roles, and has read-only access to a specific alert, could suppress that alert when it triggers. See [Define alert suppression groups to throttle sets of similar alerts](https://help.splunk.com/en/splunk-enterprise/alert-and-respond/alerting-manual/9.4/manage-alert-trigger-conditions-and-throttling/define-alert-suppression-groups-to-throttle-sets-of-similar-alerts).
Privilege escalation vulnerability in Splunk Universal Forwarder for Windows where incorrect file system permissions are assigned during installation or upgrade, allowing non-administrator users to read and modify sensitive files in the installation directory. This affects versions below 9.4.2, 9.3.4, 9.2.6, and 9.1.9, and could enable unauthorized access to credentials, configuration files, and system monitoring data. While CVSS 8.0 indicates high severity, real-world exploitation requires local access and user interaction (UI requirement per vector), limiting attack scope.
In Splunk Enterprise versions below 9.4.2, 9.3.4 and 9.2.6, and Splunk Cloud Platform versions below 9.3.2411.102, 9.3.2408.111 and 9.2.2406.118, a low-privileged user that does not hold the "admin" or "power" Splunk roles could craft a malicious payload through the pdfgen/render REST endpoint that could result in execution of unauthorized JavaScript code in the browser of a user.
In Splunk Enterprise versions below 9.4.1, 9.3.3, 9.2.5, and 9.1.8, and versions below 3.8.38 and 3.7.23 of the Splunk Secure Gateway app on Splunk Cloud Platform, a low-privileged user that does not. Rated medium severity (CVSS 4.3), this vulnerability is remotely exploitable, low attack complexity. No vendor patch available.
In the Splunk App for Lookup File Editing versions below 4.0.5, a script in the app used the `chmod` and `makedirs` Python functions in a way that resulted in overly broad read and execute. Rated low severity (CVSS 2.5). No vendor patch available.
In Splunk Enterprise versions below 9.3.3, 9.2.5, and 9.1.8 and Splunk Cloud Platform versions below 9.3.2408.103, 9.2.2406.108, 9.2.2403.113, 9.1.2312.208 and 9.1.2308.212, a low-privileged user. Rated medium severity (CVSS 5.7), this vulnerability is remotely exploitable, low attack complexity. No vendor patch available.