Splunk Enterprise vulnerabilities

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.

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

In Splunk Enterprise versions below 10.4.2, 10.2.6, 10.0.9, and 9.4.14, a user with the schedule_search capability could run arbitrary SPL commands with the highest system privilege and read every credential stored in the credential store. This is possible because scheduled search alert action configuration does not properly restrict user-specific alert action settings before the search scheduler runs alert actions.

In Splunk Enterprise below 10.4.2, 10.2.6, 10.0.9, and 9.4.13, an unauthenticated user who tricks another user into visiting a malicious web page could run unauthorized JavaScript in that user's browser. The XSS is possible because Splunk Web does not validate the origin and source of messages received by a page message handler. The attack requires phishing the victim.

In Splunk Enterprise versions below 10.4.2, 10.2.6, and 10.0.9, a user without the admin or power roles could cause the Splunk App for Splunk Observability Cloud to forward requests to Splunk Observability Cloud, including the stored access token. This is possible because the app's REST API endpoint handlers do not enforce the read_o11y_content capability before forwarding requests. The vulnerability does not affect versions 9.4 and 9.3.

In Splunk Enterprise versions below 8.2.12, 9.0.6, and 9.1.1, an attacker can create an external lookup that calls a legacy internal function. This allows the attacker to insert code into the Splunk platform installation directory.

In Splunk Enterprise versions lower than 8.2.12, 9.0.6, and 9.1.1, an attacker can exploit an absolute path traversal to execute arbitrary code located on a separate disk.

In Splunk Enterprise versions earlier than 8.2.12, 9.0.6, and 9.1.1, a dynamic link library (DLL) references an insecure path for the OPENSSLDIR build definition. An attacker can exploit this reference to install malicious code, leading to privilege escalation on the Windows machine.

In Splunk Enterprise versions lower than 8.2.12, 9.0.6, and 9.1.1, an attacker can execute a specially crafted query that allows for the serialization of untrusted data. This enables the attacker to execute arbitrary code.

In Splunk Enterprise versions lower than 8.2.12, 9.0.6, and 9.1.1, an attacker can use the `printf` SPL function to perform a denial of service (DoS) against the Splunk Enterprise instance.

In Splunk Enterprise versions lower than 9.0.6 and 8.2.12, a malicious actor can send a malformed SAML request to the `/saml/acs` REST endpoint which can cause a denial of service through a crash or hang of the Splunk daemon.

In Splunk Enterprise versions below 9.1.1, 9.0.6, and 8.2.12, an attacker can craft a special web request that can result in reflected cross-site scripting (XSS) on the “/app/search/table” web endpoint. Exploitation of this vulnerability can lead to the execution of arbitrary commands on the Splunk platform instance.