CVE Vulnerability Catalog

A user with a role that has the schedule_search capability could store a malicious script in an alert trigger condition field. When another user opens the crafted link, the script runs in that user's browser and could access all data available to that user. The vulnerability is due to using the alert threshold value in generated alert trigger condition markup without escaping special characters.

In Splunk Enterprise versions below 10.4.2, 10.2.6, 10.0.9, and 9.4.14, a user without admin or power roles could move files readable by the Splunk account into a lookup they control. This could allow access to data and affect system integrity and availability.

In Splunk Enterprise versions below 10.4.1, 10.2.5, 10.0.9, and 9.4.14, an unauthenticated user who can reach the Splunk management port could store an SPL pipeline that runs when an administrator opens the Add Data forwarder workflow. The SPL pipeline could access all relevant data, affect system integrity, and affect availability. The SPL injection is possible because Deployment Server client identifiers are placed into dispatched searches without neutralizing special characters.

In Splunk Enterprise versions below 10.4.2, 10.2.6, 10.0.9, and 9.4.14, a user without the "admin" or "power" roles could execute arbitrary code on the Splunk platform instance through Splunk Web Manager Configuration. The user could then access all relevant data and affect system integrity and availability. The vulnerability exists because Splunk Web Manager Configuration evaluates manager configuration values, and the REST API path for manager configuration does not require the permission that normally controls manager configuration writes.

In Splunk Enterprise versions below 10.4.2, 10.2.6, 10.0.9, and 9.4.14, a user without the "admin" or "power" roles could perform Remote Code Execution (RCE) by submitting crafted Splunk Web Manager Configuration content. The user could then access all relevant data and affect system integrity and availability. The vulnerability exists because Splunk Web evaluates manager XML expressions without sufficient input restrictions, and the associated configuration route does not require the capability expected for manager configuration changes.

In Splunk Enterprise versions below 10.4.2, 10.2.6, 10.0.9, and 9.4.14, a user without the "admin" or "power" roles could perform Remote Code Execution (RCE) by uploading a malicious knowledge bundle and causing it to be used by distributed search, which can allow for access to all relevant data and affect system integrity and availability. The vulnerability exists because the REST API endpoint for knowledge bundle upload does not require the high-privilege capability edit_dist_peer, and distributed search accepts caller-supplied knowledge bundle selections from users who do not hold that capability.

In Splunk Enterprise versions below 10.4.1, 10.2.6, 10.0.9, and 9.4.14, an unauthenticated user who can read the Hypertext Markup Language (HTML) source of a page that embeds a Splunk report could use exposed session material to access all relevant data and affect system integrity. The vulnerability is possible because the dispatch archive download path does not correctly enforce the embedded-report authorization boundary and includes sensitive session material in archived search-job data.

In Splunk Enterprise versions below 10.4.2, 10.2.6, 10.0.9, and 9.4.14, an unauthenticated user who has an embedded report token could download the dispatch archive for an embedded report search job and use exposed session material to access all relevant data and affect system integrity on the Splunk platform instance. The vulnerability is possible because the embedded report authorization flow does not block dispatch archive download requests before Splunk Enterprise begins sending the archive to the requester.

In Splunk Enterprise versions below 10.4.2, 10.2.6, 10.0.9, and 9.4.14, an unauthenticated user who has an embedded report token could download the associated search job dispatch archive, recover session material, and use it to access all relevant data available to the report owner and affect system integrity, including by performing administrative actions when the owner holds the "admin" Splunk role. The vulnerability is possible because embedded report access does not block Representational State Transfer (REST) API dispatch archive download requests.

In Splunk Enterprise versions below 10.4.2, 10.2.6, 10.0.9, and 9.4.14, a low-privileged user without 'admin' or 'power' roles can inject SQL through the REST API. This is possible because the REST API does not properly neutralize user-supplied filter values, allowing attacker-controlled text to be evaluated as part of a database query.

In Splunk Enterprise versions below 10.4.2 and 10.2.6, a user without 'admin' or 'power' roles can delete SPL2 modules belonging to other users through the data management orchestrator interface. The vulnerability is due to missing ownership verification before deletion (broken object level authorization).

In Splunk Enterprise 10.4 versions below 10.4.2, an unauthenticated user could read Prometheus service metrics from the Edge Processor SPL2 Preview sidecar, including service details that expose relevant runtime and build metadata for the sidecar. The vulnerability does not affect Splunk Enterprise versions below 10.4. The information disclosure is possible because the Prometheus metrics endpoint in the Edge Processor SPL2 Preview sidecar lacks authentication, which lets any client that can reach the sidecar retrieve the metrics without credentials.

In 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, a user without 'admin' or 'power' roles can read Spacebridge private keys via the Key Value Store REST API. The vulnerability occurs on instances upgraded from older versions when private-key migration is incomplete, leaving keys in a collection with an insecure default ACL.

In Splunk Enterprise below 10.4.2, 10.2.6, 10.0.9, and 9.4.14, a user with the rest_properties_get capability can read encrypted stored credentials via the REST API. The vulnerability is due to incorrect permission assignment: the properties REST endpoint requires rest_properties_get instead of list_storage_passwords to read stored credentials.

In Splunk Enterprise for Windows versions below 10.4.2, 10.2.6, 10.0.9, 9.4.13, and 9.3.14, a local user with access to the Windows host could bind to the management port before Splunk Enterprise starts, intercept authentication tokens from child processes, and use those tokens to compromise all relevant data and system integrity available to the user account running Splunk Enterprise. The vulnerability is possible because the Windows management-port listener does not apply exclusive address binding protections before the service starts.

In 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, a user without 'admin' or 'power' roles can register an arbitrary companion app and cause Splunk Secure Gateway to forward mobile user requests, including tokens, to an attacker-controlled URL. The vulnerability is due to a hard-coded cryptographic key in the companion app registration handler allowing unrestricted callback URL registration.

In 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, a user with permissions to list storage passwords but without Splunk Secure Gateway admin privileges can access MDM signing secrets, compromising mobile-device enrollment trust. The vulnerability is due to REST API endpoints for deployment bundle, SAML setup, and companion app workflows not requiring Splunk Secure Gateway admin privileges.

In 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, a user without 'admin' or 'power' roles can read sensitive SAML setup and instance settings information via Splunk Secure Gateway REST API endpoints. The vulnerability is due to these endpoints not enforcing authorization requirements before returning configuration information.

In Splunk Enterprise below 10.4.1, 10.2.6, 10.0.8, and 9.4.13, a user without 'admin' or 'power' roles can trick another user into running arbitrary SPL commands through the Data Model Editor using the victim's permissions. The vulnerability is due to missing SPL safeguards for risky commands when the Data Model Editor runs the base search for auto-extracted fields. The attack requires phishing the victim.

In Splunk Enterprise versions below 10.4.2, 10.2.6, 10.0.9, 9.4.14, and 9.3.14, an unauthenticated user could cause another user to dispatch arbitrary SPL pipelines from Dataset Explorer with the same privileges as that user. This is possible because Dataset Explorer does not validate or escape dataset names before building SPL searches and does not apply SPL safeguards for risky commands. The attack requires phishing the user into opening a crafted link.