In Splunk Enterprise versions below 10.4.1, 10.2.5, 10.0.8, and 9.4.13, and Splunk Cloud Platform versions below 10.5.2605.0, 10.4.2604.7, 10.3.2512.16, 10.2.2510.18, and 10.1.2507.24, an attacker could trick a user that holds a role with the listdeploymentserver capability into running arbitrary Search Processing Language (SPL) searches on their behalf as splunk-system-user, allowing for access to stored credentials and indexed data.<br><br>The vulnerability is possible because Deployment Server endpoints in Splunk Web do not validate Cross-Site Request Forgery (CSRF) tokens on GET requests, and caller-supplied input is not correctly neutralized before it is placed into an SPL search.

In Splunk Enterprise versions below 10.4.1, 10.2.5, 10.0.8, 9.4.13, and 9.3.14, and Splunk Cloud Platform versions below 10.5.2605.0, 10.4.2604.6, 10.2.2510.18, and 10.1.2507.24, a user who holds a role that contains the editlocalapps and installapps capabilities could cause a legitimate app installation to write files outside the intended app directory, into $SPLUNKHOME/etc/ and its subdirectories.<br><br>The vulnerability is caused by a path traversal in the app installation workflow, which does not restrict the installation path to the intended app directory.

In Splunk Enterprise versions below 10.4.1, 10.2.5, 10.0.8, and 9.4.13, and Splunk Cloud Platform versions below 10.5.2605.0, 10.4.2604.6, 10.3.2512.15, 10.2.2510.18, and 10.1.2507.24, a low-privileged user that does not hold the 'admin' or 'power' Splunk roles could view stored credential hashes when they access the /servicesNS/-/-/storage/passwords REST endpoint through the |rest Search Processing Language (SPL) command.<br><br>The exposure happens because the |rest SPL command returns the encrpassword field in the results of the /servicesNS/-/-/storage/passwords REST endpoint.

In Splunk Enterprise versions below 10.2.2 and 10.0.5, and Splunk Cloud Platform versions below 10.3.2512.8, 10.2.2510.11, 10.1.2507.21, and 10.0.2503.13, a user with a role that has access to the internal index could view session cookies and response bodies that contain sensitive data.

In Splunk Enterprise versions below 10.2.2, 10.0.5, 9.4.11, and 9.3.12, and Splunk Cloud Platform versions below 10.4.2603.1, 10.3.2512.9, 10.2.2510.11, 10.1.2507.21, 10.0.2503.13, and 9.3.2411.129, a low-privileged user that does not hold the ‘admin’ or ‘power’ Splunk roles could cause a Denial of Service by exploiting the coldToFrozen.sh script in the splunkarchiver app to rename critical Splunk directories, making the instance non-functional.<br><br>The Denial of Service is possible because of missing input validation in the coldToFrozen.sh script, which accepts arbitrary file paths and renames them without restricting operations to safe directories.

In Splunk Enterprise 10.2 versions below 10.2.4 and 10 versions below 10.0.7, an unauthenticated user could create or truncate arbitrary files through a PostgreSQL sidecar service endpoint. The vulnerability exists because the PostgreSQL sidecar service endpoint lacks authentication controls, allowing any network-reachable user to invoke file operations without credentials. Splunk Enterprise versions 9.4 and earlier are not affected. If you cannot immediately upgrade to a fixed version, you can mitigate this vulnerability by disabling the PostgreSQL sidecar service.

In Splunk Enterprise versions below 10.2.4 and 10.0.7, and Splunk Cloud Platform versions below 10.4.2604.0, 10.3.2512.12, 10.2.2510.15, 10.1.2507.23, 10.0.2503.14, and 9.3.2411.131, a user who holds a Splunk role that contains the high-privilege capability editsavedsearchowner could reassign saved search ownership to users outside their authorized scope. The ownership reassignment endpoint lacks access control.

In Splunk Enterprise versions below 10.2.4, 10.0.7, 9.4.12, and 9.3.13, and Splunk Cloud Platform versions below 10.3.2512.13, 10.2.2510.15, 10.1.2507.23, and 9.3.2411.132, a low-privileged user that does not hold the 'admin' or 'power' Splunk roles could craft a malicious classic dashboard that exfiltrates sensitive data to an external server when a higher-privileged user views it, bypassing the external content restriction through a Cascading Style Sheets (CSS) injection.<br><br>The Trusted Domains security check does not fully validate inline style attribute values, which can allow for outbound requests to untrusted domains and credential exfiltration when a victim views a crafted dashboard.

In Splunk Enterprise versions below 10.2.4, 10.0.7, 9.4.12, and 9.3.13, and Splunk Cloud Platform versions below 10.3.2512.13, 10.2.2510.15, 10.1.2507.23, and 9.3.2411.132, a low-privileged user that does not hold the "admin" or "power" Splunk roles could craft a malicious classic dashboard that exfiltrates sensitive data to an external server.

The vulnerability exists because URL validation on the external content dialog is incomplete, which can allow for requests to untrusted domains when a user interacts with a crafted dashboard.

In Splunk Enterprise versions below 10.2.4, 10.0.7, 9.4.12, and 9.3.13, and Splunk Cloud Platform versions below 10.3.2512.13, 10.2.2510.15, 10.1.2507.23, and 9.3.2411.132, a low-privileged user that does not hold the 'admin' or 'power' Splunk roles could cause data exfiltration through classic dashboards by redirecting a victim to an external site using a protocol-relative URL in a drill-down link.<br><br>The vulnerability exists because the URL classifier in classic dashboards only recognizes http:// and https:// schemes when checking for external URLs. Protocol-relative URLs such as //attacker.com bypass this check entirely, and Splunk Web does not show the external-navigation warning dialog to the victim.

In Splunk Enterprise versions below 10.2.4, 10.0.7, 9.4.12, and 9.3.13, and Splunk Cloud Platform versions below 10.3.2512.13, 10.2.2510.15, 10.1.2507.23, and 9.3.2411.132, a low-privileged user that does not hold the "admin" or "power" Splunk roles could craft a classic dashboard that exfiltrates sensitive data from the browser of a higher-privileged user who views it.

The exfiltration is possible because classic dashboard panels do not fully validate style attribute values, which can allow for requests to reach external domains outside the configured Trusted Domains List.

The vulnerability requires the attacker to phish the 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 10.2.4, 10.0.7, 9.4.12, and 9.3.13, and Splunk Cloud Platform versions below 10.3.2512.11, 10.2.2510.15, 10.1.2507.23, and 9.3.2411.132, a low-privileged user that does not hold the "admin" or "power" Splunk roles could store a malicious script in a classic dashboard HTML panel, causing unauthorized JavaScript code to execute in the browser of another user.

The vulnerability requires the attacker to phish the 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 10.2.4, 10.0.7, 9.4.12, and 9.3.13, Splunk Cloud Platform versions below 10.3.2512.12, 10.2.2510.14, 10.1.2507.22, and 9.3.2411.132, and Splunk Secure Gateway versions below 3.10.6, 3.9.20, and 3.8.67, a low-privileged user that does not hold the 'admin' or 'power' Splunk roles could perform a Remote Code Execution (RCE) through the Splunk Secure Gateway app.<br><br>The Remote Code Execution is possible because of unsafe deserialization of App Key Value Store (KV Store) data through the ‘jsonpickle’ Python library, which reconstructs arbitrary Python objects from specially crafted JavaScript Object Notation (JSON) without adequate validation.

In Splunk Enterprise versions below 10.2.4, 10.0.7, 9.4.12, and 9.3.13, and Splunk Cloud Platform versions below 10.4.2604.3, 10.3.2512.12, 10.2.2510.14, 10.1.2507.22, and 9.3.2411.132, a low-privileged user that does not hold the "admin" or "power" Splunk roles could send server-side requests to arbitrary internal destinations through the Dashboard Studio PDF export feature.

The vulnerability exists because the trusted-domain validation uses a prefix match that can be bypassed with attacker-controlled subdomains (for example, docs.splunk.com.evil.com), and because the PDF export service follows HTTP redirects automatically without re-validating each redirect target against the allowlist.

In Splunk Enterprise versions below 8.2.9, 8.1.12, and 9.0.2, sending a malformed file through the Splunk-to-Splunk (S2S) or HTTP Event Collector (HEC) protocols to an indexer results in a blockage or denial-of-service preventing further indexing.

In Splunk Enterprise versions below 8.2.9, 8.1.12, and 9.0.2, an authenticated user can execute arbitrary code through the dashboard PDF generation component.

In Splunk Enterprise versions below 8.2.9, 8.1.12, and 9.0.2, an authenticated user can run risky commands using a more privileged user’s permissions to bypass SPL safeguards for risky commands https://docs.splunk.com/Documentation/SplunkCloud/latest/Security/SPLsafeguards  in the Analytics Workspace. The vulnerability requires the attacker to phish the victim by tricking them into initiating a request within their browser. The attacker cannot exploit the vulnerability at will.

In Splunk Enterprise versions below 8.2.9 and 8.1.12, the way that the ‘tstats command handles Javascript Object Notation (JSON) lets an attacker bypass SPL safeguards for risky commands https://docs.splunk.com/Documentation/SplunkCloud/latest/Security/SPLsafeguards . The vulnerability requires the attacker to phish the victim by tricking them into initiating a request within their browser.

In Splunk Enterprise versions below 8.1.12, 8.2.9, and 9.0.2, an authenticated user can inject and store arbitrary scripts that can lead to persistent cross-site scripting (XSS) in the object name of a Data Model.

In Splunk Enterprise versions below 8.1.12, 8.2.9, and 9.0.2, a View allows for a Reflected Cross Site Scripting via JavaScript Object Notation (JSON) in a query parameter when outputmode=radio.

In Splunk Enterprise versions below 8.1.12, 8.2.9, and 9.0.2, a remote user who can create search macros and schedule search reports can cause a denial of service through the use of specially crafted search macros.

In Splunk Enterprise versions below 8.1.12, 8.2.9, and 9.0.2, an authenticated user can perform an extensible markup language (XML) external entity (XXE) injection via a custom View. The XXE injection causes Splunk Web to embed incorrect documents into an error.

In Splunk Enterprise versions below 8.2.9, 8.1.12, and 9.0.2, an authenticated user can run arbitrary operating system commands remotely through the use of specially crafted requests to the mobile alerts feature in the Splunk Secure Gateway app.

In Splunk Enterprise versions below 8.2.9 and 8.1.12, the way that the rex search command handles field names lets an attacker bypass SPL safeguards for risky commands https://docs.splunk.com/Documentation/SplunkCloud/latest/Security/SPLsafeguards . The vulnerability requires the attacker to phish the victim by tricking them into initiating a request within their browser. The attacker cannot exploit the vulnerability at will.

In Splunk Enterprise versions below 8.1.12, 8.2.9, and 9.0.2, a remote user that holds the “power” Splunk role can store arbitrary scripts that can lead to persistent cross-site scripting (XSS). The vulnerability affects instances with Splunk Web enabled.

In Splunk Enterprise versions below 8.1.12, 8.2.9, and 9.0.2, Splunk Enterprise fails to properly validate and escape the Host header, which could let a remote authenticated user conduct various attacks against the system, including cross-site scripting and cache poisoning.

In Splunk Enterprise versions below 10.2.2, 10.0.5, 9.4.10, and 9.3.11, and Splunk Cloud Platform versions below 10.4.2603.0, 10.3.2512.6, 10.2.2510.10, 10.1.2507.20, 10.0.2503.13, and 9.3.2411.127, a user who holds a role that contains the high-privilege capability editusercould create a specially crafted username that includes a null byte or a non-UTF-8 percent-encoded byte due to improper input validation.<br><br>This could lead to inconsistent conversion of usernames into a proper format for storage and account management inconsistencies, such as being unable to edit or delete affected users.

In Splunk Enterprise versions below 10.2.2, 10.0.5, 9.4.10, and 9.3.11, and Splunk Cloud Platform versions below 10.4.2603.0, 10.3.2512.6, 10.2.2510.10, 10.1.2507.19, 10.0.2503.13, and 9.3.2411.127, a low-privileged user that does not hold the admin or power Splunk roles, has write permission on the app, and does not hold the high-privilege capability acceleratedatamodel, could turn on or off Data Model Acceleration due to improper access control.

In Splunk Enterprise versions below 10.2.1, 10.0.5, 9.4.10, and 9.3.11, and Splunk Cloud Platform versions below 10.4.2603.0, 10.3.2512.5, 10.2.2510.9, 10.1.2507.19, 10.0.2503.13, and 9.3.2411.127, a low-privileged user that does not hold the admin or power Splunk roles could potentially perform a Remote Code Execution (RCE) by uploading a malicious file to the $SPLUNKHOME/var/run/splunk/apptemp directory due to improper handling and insufficient isolation of temporary files within the apptemp directory.

In Splunk Enterprise versions below 10.2.1 and 10.0.4, and Splunk Cloud Platform versions below 10.2.2510.5, 10.1.2507.16, and 10.0.2503.12, a low-privileged user that does not hold the "admin" or "power" Splunk roles could retrieve the Observability Cloud API access token through the Discover Splunk Observability Cloud app due to improper access control.

This vulnerability does not affect Splunk Enterprise versions below 9.4.9 and 9.3.10 because the Discover Splunk Observability Cloud app does not come with Splunk Enterprise.