Splunk Enterprise vulnerabilities

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 10.4 versions below 10.4.2, an unauthenticated user could retrieve the information contained in Edge Processor pipeline configurations through a REST API endpoint when Edge Processor is turned on. The vulnerability does not affect versions prior to 10.4. The vulnerability exists because the Edge Processor service endpoint lacks authentication controls.

In Splunk Enterprise versions below 10.4.2, 10.2.6, 10.0.9, and 9.4.14, a user who does not hold the "admin" or "power" Splunk roles could affect system integrity and availability by sending a crafted REST API request that deletes or temporarily overwrites files writable by the user account running Splunk Enterprise processes on a non-captain search head cluster member. The vulnerability exists because Search Head Clustering bundle replication does not validate the name of a replicated bundle file or neutralize NUL bytes before constructing the member bundle path.

In Splunk Enterprise versions below 10.4.2, 10.2.6, 10.0.9, and 9.4.14, a user who does not hold the "admin" or "power" roles could submit a crafted knowledge bundle delta to delete arbitrary files accessible to Splunk Enterprise on a cluster manager. The vulnerability is possible because knowledge bundle delta processing does not restrict removal paths to the staging directory and the endpoint does not enforce the expected authorization boundary.

In Splunk Enterprise versions below 10.4.2, 10.2.6, 10.0.9, and 9.4.14, a user who does not hold the "admin" or "power" Splunk roles could create or modify a scripted lookup through generic configuration endpoints and run an installed lookup script with the permissions of the user account running Splunk Enterprise, which could allow for access to all relevant data and affect system integrity and availability. The vulnerability exists because the generic transforms configuration endpoints do not enforce the capabilities required to create or edit external lookup definitions.

In Splunk Enterprise versions below 10.4.2, 10.2.6, 10.0.9, and 9.4.14, a user that holds a role with the schedule_search capability could configure PDF attachments in the email alert action workflow. When the email alert action runs, it could execute arbitrary SPL commands with system-level privileges, expose all relevant data, and affect system integrity and availability on the search head. The vulnerability exists because the search scheduler passes a system-level authentication context rather than the action owner context to the email alert action when it renders PDF attachments.

In Splunk Enterprise versions below 10.2.6, 10.0.9, and 9.4.14, an unauthenticated user could trick an authenticated user into running arbitrary SPL commands with the victim's permissions via a crafted Splunk Web link. The vulnerability is due to substituting URL-supplied form token values into SPL searches without sanitization. The attack requires phishing the user.

In Splunk Enterprise versions below 10.4.2, 10.2.6, 10.0.9, and 9.4.14, a user who holds a Splunk role that contains the high-privilege list_search_head_clustering capability could send a read request to Search Head Cluster member control endpoints and change cluster state, which could allow for a denial of service. The vulnerability is possible because the Search Head Cluster member control endpoints do not require a state-changing Hypertext Transfer Protocol (HTTP) request type before they apply read-only authorization.

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 could use SSRF in report notifications to send system-authenticated requests to internal Splunk services, potentially altering Search Head Cluster state and causing DoS. The vulnerability is due to missing validation of report notification paths.

In Splunk Enterprise below 10.4.2, 10.2.6, 10.0.9, and 9.4.14, a user with power role could store a malicious script in dashboard sparkline format options and execute unauthorized JavaScript in another user's browser. If the victim has admin role, the script could access all data and perform actions with admin permissions. The vulnerability is due to lack of restrictions on visualization options and missing escaping of tooltip values.

In Splunk Enterprise below 10.4.2, a user with high-privilege role managing search head clustering could use the REST API to write files to locations writable by the Splunk account, potentially enabling remote code execution. The vulnerability is due to missing authorization boundary enforcement and lack of bundle path validation.

In Splunk Enterprise versions below 10.4.2, 10.2.6, 10.0.9, and 9.4.14, a user who does not hold the "admin" or "power" Splunk roles could write dispatch metadata to an arbitrary location on the host by supplying a crafted search identifier to a REST API endpoint and affect system integrity on the host. The vulnerability exists because Splunk Enterprise does not validate the search identifier before using it to create a dispatch directory.

In Splunk Enterprise below 10.4.2, 10.2.6, 10.0.9, and 9.4.14, a user without admin or power roles could execute arbitrary SQL queries through the Data Orchestration jobs endpoint, allowing access to data stored by Data Orchestration, including other users' jobs and stored connection credentials. The vulnerability is due to building queries without parameterization.

In Splunk Enterprise below 10.4.2, 10.2.6, 10.0.9, and 9.4.14, a user with power role could store risky SPL commands in a Table Editor dataset and share it. An admin user triggers the commands when opening the dataset, potentially exposing data and modifying lookup files. The vulnerability is due to missing SPL safeguards for risky commands in the field-summary search.

In Splunk Enterprise versions below 10.4.2, 10.2.6, 10.0.9, and 9.4.14, a user with the "power" role can store attacker-controlled SPL in a Table Editor dataset and share it. When an "admin" user opens the dataset, the SPL executes with the admin's permissions, potentially exposing data and allowing limited modification. The vulnerability is due to missing SPL safeguards for risky commands in the Table Editor.

In Splunk Enterprise 10.4 below 10.4.2, an unauthenticated user could cause reload of token-signing keys via the REST API. The vulnerability is due to missing authentication or change_authentication capability requirement for the token-key reload action.

In Splunk Enterprise below 10.4.2, 10.2.6, 10.0.9, and 9.4.14, a user without admin or power roles could inject arbitrary SPL commands through the geostats command. The injected SPL runs with the permissions of another authenticated user after that user initiates the attacker-controlled geostats search. The vulnerability is due to insufficient input validation.

In Splunk Enterprise versions below 10.4.2, 10.2.6, 10.0.9, and 9.4.14, an unauthenticated user who has access to a trusted distributed search private key could forge an administrative session token, access all relevant data, affect system integrity, and disrupt service availability. The vulnerability exists because the distributed search authentication token endpoint does not require a signed request to identify a configured search peer, allowing the request to fall back to shared local key material.

In Splunk Enterprise below 10.4.2, 10.2.6, 10.0.9, and 9.4.14, an unauthenticated user could read JavaScript files outside the Splunk Web static directory. The vulnerability is due to lack of restriction of static file requests to the configured static directory.

In Splunk Enterprise versions below 10.4.2 and 10.2.6, a user without admin or power roles could delete all SPL2 modules across the instance via the REST API. This could delete exported datasets and functions, affecting system integrity and causing partial service disruption.

In Splunk Enterprise versions below 10.4.2, 10.2.6, 10.0.9, and 9.4.14, an authenticated user without edit_manager_xml capability could write a malicious Splunk Web Manager XML configuration. When the user opens the page, Splunk runs attacker-controlled OS commands.

A user with the "power" role in Splunk Enterprise can store a Dashboard Studio workflow action containing attacker-controlled SPL. When another authenticated user selects the action, Splunk runs the injected SPL with that user's permissions, potentially allowing access or modification of data. The vulnerability is due to insufficient validation of workflow-action URLs in Dashboard Studio.

In Splunk Enterprise versions below 10.4.2, 10.2.6, 10.0.9, and 9.4.14, a user with power role could store a Dashboard Studio workflow action with a crafted URL. When another user selects it, attacker-controlled JavaScript runs in their browser.

In Splunk Enterprise versions below 10.4.2, 10.2.6, 10.0.9, and 9.4.14, an unauthenticated user could trick an authenticated user into opening a crafted link to Analytics Workspace. Splunk then runs attacker-controlled SPL with the victim's permissions.

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 inject SPL into saved-search dispatch requests. This could allow unauthorized access to data and affect system integrity.

In Splunk Enterprise versions below 10.4.2, 10.2.6, 10.0.9, and 9.4.14, an unauthenticated user could trick an authenticated user into opening a crafted link to Monitoring Console. Splunk then runs attacker-controlled SPL with the victim's permissions.

An unauthenticated attacker can trick a user with the "admin" role into opening a crafted link to Monitoring Console. When opened, Splunk Enterprise runs attacker-controlled SPL with that user's permissions, potentially exposing data or modifying lookup data. The vulnerability is due to insufficient validation of data used to build dashboard searches in Monitoring Console.

A user with the "power" role can store attacker-controlled SPL in a dashboard. When another authenticated user exports the dashboard as a PDF, Splunk Enterprise runs the injected SPL with that user's permissions, potentially allowing access or modification of data. The vulnerability is due to insufficient validation of dashboard content before processing PDF exports.

An unauthenticated attacker can trick a user with the "admin" or "sc_admin" role into opening a crafted Splunk Web URL. The resulting dashboard searches could run arbitrary SPL commands with the victim's permissions, potentially exposing data and affecting search results or lookup data. The vulnerability is due to improper neutralization of caller-supplied values in Splunk Secure Gateway dashboards.

A user without the "admin" or "power" roles can store a dashboard view that runs JavaScript in another user's browser when they open it and hover over a sparkline table cell, potentially allowing access to all relevant data and system integrity. The vulnerability is due to insufficient restriction of tooltip options and lack of escaping tooltip content before display.

In Splunk Enterprise versions below 10.4.2, 10.2.6, 10.0.9, and 9.4.14, a user with power role could store a malicious ui-tour knowledge object and share it at the app level. The object can execute arbitrary JavaScript in another user's browser.

A user with the "power" role can create a malicious Splunk Web tour and cause arbitrary JavaScript to run in another user's browser when they open a crafted tour link. The JavaScript runs in the victim's browser, allowing access to all relevant data. The XSS vulnerability is due to insufficient output encoding of tour content and navigation links and accepting a tour selector value that can be treated as markup.

A user without the "admin" or "power" roles can bypass SPL safeguards for risky commands through the Job Details dashboard. The injected SPL could run with the permissions of an authenticated user who opens a crafted Job Details dashboard link. This could allow access to all relevant data and affect system integrity. The vulnerability is due to improper neutralization of a caller-supplied search identifier before placing it into SPL searches.

A user with the "user" role could craft a Dashboard Studio dashboard that runs attacker-controlled SPL for another authenticated user. The attacker-controlled SPL could access all relevant data and affect system integrity and availability. The vulnerability is due to inconsistent enforcement of the expected app-visibility authorization boundary before dashboard search query options reach search dispatch.

In Splunk Enterprise versions below 10.4.2, 10.2.6, 10.0.9, and 9.4.14, an unauthenticated user could inject arbitrary SPL into requests that search for events near a selected event. This could allow unauthorized search execution.

An unauthenticated attacker could cause an authenticated user to run arbitrary SPL searches on their behalf through the Event Type Builder. This could expose all relevant data and stored credentials. The vulnerability occurs when the Event Type Builder accepts cross-site request input and retains SPL-affecting values while building sample event searches.

In Splunk Enterprise versions below 10.4.2, 10.2.6, 10.0.9, and 9.4.14, a low-privileged user without fsh_manage capability could perform Remote Code Execution through Federated Search bundle selection. This could allow access to data and affect system integrity and availability.

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.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, 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.