In Splunk Enterprise versions below 10.4.1, 10.2.6, 10.0.9, and 9.4.14, a user who holds the "power" Splunk role could store attacker-controlled Search Processing Language (SPL) in a dashboard. When another authenticated user exports the dashboard as a Portable Document Format (PDF) file, Splunk Enterprise runs the injected SPL using the permissions of that user. The injected SPL could access or modify data available to that user. The vulnerability is possible because Splunk Web does not sufficiently validate dashboard content before processing PDF exports. The vulnerability requires the attacker to phish the affected user by tricking them into initiating a request within their browser. The user who holds the "power" Splunk role should not be able to exploit the vulnerability at will. For more information see Generate PDFs of your reports and dashboards (https://help.splunk.com/en/splunk-enterprise/create-dashboards-and-reports/reporting-manual/9.4/report-management/generate-pdfs-of-your-reports-and-dashboards) in the Splunk documentation.
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. When the authenticated user opens the link, Splunk Enterprise runs attacker-controlled Search Processing Language (SPL) using the permissions of that user. The injected SPL could access data and perform actions available to that user. The vulnerability is possible because Monitoring Console does not sufficiently validate data used to build forwarder dashboard searches. The vulnerability requires the attacker to phish the user by tricking them into opening the crafted link. The unauthenticated user should not be able to exploit the vulnerability at will.
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 inject Search Processing Language (SPL) into saved-search dispatch requests. This could allow for unauthorized access to all relevant data and affect system integrity within Splunk Enterprise. The vulnerability is possible because Splunk Enterprise does not correctly validate caller-supplied time values before using them in saved-search dispatch. For more information see Search endpoint descriptions (https://help.splunk.com/en/splunk-enterprise/rest-api-reference/10.2/search-endpoints/search-endpoint-descriptions) in the Splunk documentation.
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. When the authenticated user opens the link, Splunk Enterprise runs attacker-controlled Search Processing Language (SPL) using the permissions of that user. The injected SPL could access data and perform actions available to that user. The vulnerability is possible because Analytics Workspace does not sufficiently validate data used to build searches. The vulnerability requires the attacker to phish the user by tricking them into opening the crafted link. The unauthenticated user should not be able to exploit the vulnerability at will.
In Splunk Enterprise versions below 10.4.2, 10.2.6, 10.0.9, and 9.4.14, a user who holds the "power" Splunk role could store a Dashboard Studio workflow action containing attacker-controlled Search Processing Language (SPL). When another authenticated user selects the action from Event Actions and selects Continue, Splunk Enterprise runs the injected SPL using the permissions of that user. The injected SPL could access or modify data available to that user. The vulnerability is possible because Dashboard Studio does not sufficiently validate workflow-action URLs before submitting requests. The vulnerability requires the attacker to phish the affected user by tricking them into initiating a request within their browser. The user who holds the "power" Splunk role should not be able to exploit the vulnerability at will.
In Splunk Enterprise versions below 10.4.2, 10.2.6, 10.0.9, and 9.4.14, an authenticated user who does not hold a role with the edit_manager_xml capability could write a malicious Splunk Web Manager Extensible Markup Language (XML) configuration. When the same user opens the affected Splunk Web Manager page, Splunk Enterprise runs attacker-controlled operating-system commands as the user account running Splunk Enterprise. The vulnerability is possible because Splunk Web does not require the edit_manager_xml capability before accepting Splunk Web Manager XML configuration changes.
In Splunk Enterprise versions below 10.4.2, 10.2.6, 10.0.9, and 9.4.14, an unauthenticated user could cause an authenticated user to run arbitrary Search Processing Language (SPL) searches on their behalf through the Event Type Builder. This could expose all relevant data and stored credentials. The vulnerability is possible when the Event Type Builder accepts cross-site request input and retains SPL-affecting values while building sample event searches. The vulnerability requires the attacker to phish the affected user by tricking them into initiating a request within their browser. The unauthenticated user should not be able to exploit the vulnerability at will. For more information see Automatically find and build event types (https://help.splunk.com/en/splunk-enterprise/manage-knowledge-objects/knowledge-management-manual/9.0/event-types/automatically-find-and-build-event-types) in the Splunk documentation.
In Splunk Enterprise versions below 10.4.2, 10.2.6, 10.0.9, and 9.4.14, a user who holds the "power" Splunk role could create a malicious Splunk Web tour and cause arbitrary JavaScript to run in the browser of another user when that user opens a crafted tour link. The JavaScript runs in the browser of the affected user, allowing for access to all relevant data available to that user. The Cross-Site Scripting (XSS) vulnerability is possible because Splunk Web renders tour content and tour navigation links without sufficient output encoding and accepts a tour selector value that can be treated as markup. The vulnerability requires another user to open a crafted tour link. The user who holds the "power" Splunk role should not be able to trigger JavaScript execution in another user's browser without that user interaction.
In Splunk Enterprise versions below 10.4.2, 10.2.6, 10.0.9, and 9.4.14, a user who holds the "power" Splunk role could store a malicious ui-tour knowledge object that matches an auto-tour page name and share the object at the app level. The object can execute arbitrary JavaScript in the browser of another authenticated user who visits a standard Splunk Web page. The JavaScript could expose all relevant data and affect system integrity within the second user permissions. The Cross-Site Scripting (XSS) vulnerability is possible because Splunk Web resolves auto-tour entries from the app namespace and uses untrusted tour content when building the tour image.
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 store a dashboard view that runs JavaScript in the browser of another user who opens it and hovers over a sparkline table cell, allowing for access to all relevant data and system integrity available to that user. The vulnerability is possible because the dashboard table renderer does not sufficiently restrict tooltip options or escape tooltip content before display.