35 advisories tracked · Splunk (prodsec@splunk.com CNA) via NVD · checked automatically every minute
Pick your product and enter the exact software release it runs. We match it against the affected/fixed versions in Splunk's recent advisories.
Splunk (prodsec@splunk.com CNA) via NVD
Splunk is its own CVE Numbering Authority. VulniPulse ingests Splunk's CVEs from the NVD CNA feed (prodsec@splunk.com), each linking to its SVD-YYYY-NNNN advisory on advisory.splunk.com. Covers Splunk Enterprise, Splunk Cloud Platform, the Universal Forwarder, IT Service Intelligence (ITSI), SOAR, Enterprise Security and Splunk apps/add-ons — the SIEM at the centre of most SOCs, so a security-team audience that patches on advisory day.
Visit Splunk security advisoriesIn Splunk Enterprise versions below 9.3.2, 9.2.4, and 9.1.7, and versions below 3.4.261 and 3.7.13 of the Splunk Secure Gateway app on Splunk Cloud Platform, a low-privileged user that does not hold the “admin“ or “power“ Splunk roles could perform a Remote Code Execution (RCE).
In Splunk Enterprise versions below 9.3.2, 9.2.4, and 9.1.7 and Splunk Cloud Platform versions below 9.3.2408.101, 9.2.2406.106, 9.2.2403.111, and 9.1.2312.206, an SPL command can potentially disclose sensitive information. The vulnerability requires the exploitation of another vulnerability, such as a Risky Commands Bypass, for successful exploitation.
In Splunk Enterprise versions below 9.3.2, 9.2.4, and 9.1.7 and Splunk Cloud Platform versions below 9.2.2406.107, 9.2.2403.109, and 9.1.2312.206, a low-privileged user that does not hold the “admin“ or “power“ Splunk roles could run a saved search with a risky command using the permissions of a higher-privileged user to bypass the SPL safeguards for risky commands on “/en-US/app/search/report“ endpoint through “s“ parameter.<br>The vulnerability requires the attacker to phish the victim by tricking them into initiating a request within their browser. The authenticated user should not be able to exploit the vulnerability at will.
In Splunk Enterprise versions below 9.3.2, 9.2.4, and 9.1.7 and versions below 3.2.462, 3.7.18, and 3.8.5 of the Splunk Secure Gateway app on Splunk Cloud Platform, a low-privileged user that does not hold the “admin“ or “power“ Splunk roles could see alert search query responses using Splunk Secure Gateway App Key Value Store (KVstore) collections endpoints due to improper access control.
In Splunk Enterprise versions below 9.3.0, 9.2.4, and 9.1.7 and Splunk Cloud Platform versions below 9.1.2312.206, a low-privileged user that does not hold the “admin“ or “power“ Splunk roles, that has a username with the same name as a role with read access to dashboards, could see the dashboard name and the dashboard XML by cloning the dashboard.
In Splunk Enterprise versions below 9.3.1, and 9.2.0 versions below 9.2.3, and Splunk Cloud Platform versions below 9.2.2403.103, 9.1.2312.200, 9.1.2312.110 and 9.1.2308.208, a low-privileged user that does not hold the "admin" or "power" Splunk roles could run a search as the "nobody" Splunk user in the SplunkDeploymentServerConfig app. This could let the low-privileged user access potentially restricted data.
In Splunk Enterprise versions below 9.2.3 and 9.1.6 and Splunk Cloud Platform versions below 9.2.2403.108 and 9.1.2312.205, a low-privileged user that does not hold the "admin" or "power" Splunk roles could create a malicious payload through a custom configuration file that the "api.uri" parameter from the "/manager/search/apps/local" endpoint in Splunk Web calls. This could result in execution of unauthorized JavaScript code in the browser of a user.
In Splunk Enterprise versions below 9.2.3 and 9.1.6 and Splunk Cloud Platform versions below 9.2.2403, a low-privileged user that does not hold the "admin" or "power" Splunk roles could craft a malicious payload through Scheduled Views that could result in execution of unauthorized JavaScript code in the browser of a user.
In Splunk Enterprise versions below 9.3.1, 9.2.3, and 9.1.6 and Splunk Cloud Platform versions below 9.2.2403.108, and 9.1.2312.204, a low-privileged user that does not hold the "admin" or "power" Splunk roles could change the maintenance mode state of App Key Value Store (KVStore) through a Cross-Site Request Forgery (CSRF).
In Splunk Enterprise versions below 9.3.1, 9.2.3, and 9.1.6 and Splunk Cloud Platform versions below 9.2.2403.107, 9.1.2312.204, and 9.1.2312.111, a low-privileged user that does not hold the "admin" or "power" Splunk roles could craft a search query with an improperly formatted "INGEST_EVAL" parameter as part of a [Field Transformation](https://docs.splunk.com/Documentation/Splunk/latest/Knowledge/Managefieldtransforms) which could crash the Splunk daemon (splunkd).
In Splunk Enterprise versions below 9.2.3 and 9.1.6, and Splunk Secure Gateway versions on Splunk Cloud Platform versions below 3.4.259, 3.6.17, and 3.7.0, a low-privileged user that does not hold the "admin" or "power" Splunk roles can see App Key Value Store (KV Store) deployment configuration and public/private keys in the Splunk Secure Gateway App.
In Splunk Enterprise versions below 9.2.2, 9.1.5, and 9.0.10 and Splunk Cloud Platform versions below 9.1.2312, an admin user could store and execute arbitrary JavaScript code in the browser context of another Splunk user through the conf-web/settings REST endpoint. This could potentially cause a persistent cross-site scripting (XSS) exploit.
In Splunk Enterprise versions below 9.2.2, 9.1.5, and 9.0.10 and Splunk Cloud Platform versions below 9.1.2312.200, a low-privileged user that does not hold the admin or power Splunk roles could create notifications in Splunk Web Bulletin Messages that all users on the instance receive.
In Splunk Enterprise versions below 9.2.2, 9.1.5, and 9.0.10 and Splunk Cloud Platform versions below 9.1.2312.109 and 9.1.2308.207, an authenticated user could create an external lookup that calls a legacy internal function. The authenticated user could use this internal function to insert code into the Splunk platform installation directory. From there, the user could execute arbitrary code on the Splunk platform Instance.
In Splunk Enterprise versions below 9.2.2, 9.1.5, and 9.0.10 and Splunk Cloud Platform versions below 9.1.2312.109 and 9.1.2308.207, an attacker could trigger a null pointer reference on the cluster/config REST endpoint, which could result in a crash of the Splunk daemon.
In Splunk Enterprise versions below 9.2.2, 9.1.5, and 9.0.10 and Splunk Cloud Platform versions below 9.1.2312.109, an attacker could determine whether or not another user exists on the instance by deciphering the error response that they would likely receive from the instance when they attempt to log in. This disclosure could then lead to additional brute-force password-guessing attacks. This vulnerability would require that the Splunk platform instance uses the Security Assertion Markup Language (SAML) authentication scheme.
In Splunk Enterprise versions below 9.2.2, 9.1.5, and 9.0.10 and Splunk Cloud Platform versions below 9.1.2312.200 and 9.1.2308.207, a low-privileged user that does not hold the admin or power Splunk roles could create experimental items.
In Splunk Enterprise versions below 9.2.2, 9.1.5, and 9.0.10 and Splunk Cloud Platform versions below 9.1.2312.200 and 9.1.2308.207, a low-privileged user that does not hold the admin or power Splunk roles could craft a malicious payload through a View and Splunk Web Bulletin Messages that could result in execution of unauthorized JavaScript code in the browser of a user.
In Splunk Enterprise versions below 9.2.2, 9.1.5, and 9.0.10 and Splunk Cloud Platform versions below 9.1.2312.200 and 9.1.2308.207, a low-privileged user that does not hold the admin or power Splunk roles could craft a malicious payload through a Splunk Web Bulletin Messages that could result in execution of unauthorized JavaScript code in the browser of a user.
In Splunk Enterprise versions below 9.2.2, 9.1.5, and 9.0.10 and Splunk Cloud Platform versions below 9.1.2312.200 and 9.1.2308.207, a low-privileged user that does not hold the admin or power Splunk roles could craft a malicious payload through a View that could result in execution of unauthorized JavaScript code in the browser of a user. The “url” parameter of the Dashboard element does not have proper input validation to reject invalid URLs, which could lead to a Persistent Cross-site Scripting (XSS) exploit.
In Splunk Enterprise versions below 9.2.2, 9.1.5, and 9.0.10 and Splunk Cloud Platform versions below 9.2.2403.100, an authenticated, low-privileged user that does not hold the admin or power Splunk roles could send a specially crafted HTTP POST request to the datamodel/web REST endpoint in Splunk Enterprise, potentially causing a denial of service.
In Splunk Enterprise versions below 9.2.2, 9.1.5, and 9.0.10 and Splunk Cloud Platform versions below 9.1.2312.200, an authenticated, low-privileged user who does not hold the admin or power Splunk roles could upload a file with an arbitrary extension using the indexing/preview REST endpoint.
In Splunk Enterprise versions below 9.2.2, 9.1.5, and 9.0.10 and Splunk Cloud Platform versions below 9.1.2312.200 and 9.1.2308.207, an authenticated user could run risky commands using the permissions of a higher-privileged user to bypass SPL safeguards for risky commands in the Analytics Workspace. The vulnerability requires the authenticated user to phish the victim by tricking them into initiating a request within their browser. The authenticated user should not be able to exploit the vulnerability at will.
In Splunk Enterprise versions below 9.0.5, 8.2.11, and 8.1.14, and Splunk Cloud Platform versions below 9.0.2303.100, a low-privileged user can trigger an HTTP response splitting vulnerability with the ‘rest’ SPL command that lets them potentially access other REST endpoints in the system arbitrarily.
In versions of Splunk Enterprise below 9.0.5, 8.2.11, and 8.1.14, and Splunk Cloud Platform below version 9.0.2303.100, a low-privileged user who holds a role that has the ‘edit_user’ capability assigned to it can escalate their privileges to that of the admin user by providing specially crafted web requests.
On Splunk Enterprise versions below 9.0.5, 8.2.11, and 8.1.14, and in Splunk Cloud Platform versions below 9.0.2303.100, an unauthorized user can access the {{/services/indexing/preview}} REST endpoint to overwrite search results if they know the search ID (SID) of an existing search job.
In Splunk Enterprise versions below 9.0.5, 8.2.11, and 8.1.14, and Splunk Cloud Platform versions below 9.0.2303.100, an attacker can exploit a vulnerability in the {{dump}} SPL command to cause a denial of service by crashing the Splunk daemon.
In Splunk Enterprise versions below 9.0.5, 8.2.11, and 8.1.14, and in Splunk Cloud Platform versions below 9.0.2303.100, a low-privileged user can perform an unauthorized transfer of data from a search using the ‘copyresults’ command if they know the search ID (SID) of a search job that has recently run.
In Splunk Enterprise versions below 9.0.5, 8.2.11. and 8.1.14, and Splunk Cloud Platform versions below 9.0.2303.100, a low-privileged user who holds the ‘user’ role can see the hashed version of the initial user name and password for the Splunk instance by using the ‘rest’ SPL command against the ‘conf-user-seed’ REST endpoint.
In Splunk Add-on Builder (AoB) versions below 4.1.2 and the Splunk CloudConnect SDK versions below 3.1.3, requests to third-party APIs through the REST API Modular Input incorrectly revert to using HTTP to connect after a failure to connect over HTTPS occurs.
In Splunk Enterprise and Universal Forwarder versions before 9.0, the Splunk command-line interface (CLI) did not validate TLS certificates while connecting to a remote Splunk platform instance by default. After updating to version 9.0, see Configure TLS host name validation for the Splunk CLI https://docs.splunk.com/Documentation/Splunk/9.0.0/Security/EnableTLSCertHostnameValidation#Configure_TLS_host_name_validation_for_the_Splunk_CLI to enable the remediation. The vulnerability does not affect the Splunk Cloud Platform. At the time of publishing, we have no evidence of exploitation of this vulnerability by external parties. The issue requires conditions beyond the control of a potential bad actor such as a machine-in-the-middle attack. Hence, Splunk rates the complexity of the attack as High.
Splunk Enterprise peers in Splunk Enterprise versions before 9.0 and Splunk Cloud Platform versions before 8.2.2203 did not validate the TLS certificates during Splunk-to-Splunk communications by default. Splunk peer communications configured properly with valid certificates were not vulnerable. However, an attacker with administrator credentials could add a peer without a valid certificate and connections from misconfigured nodes without valid certificates did not fail by default. For Splunk Enterprise, update to Splunk Enterprise version 9.0 and Configure TLS host name validation for Splunk-to-Splunk communications (https://docs.splunk.com/Documentation/Splunk/9.0.0/Security/EnableTLSCertHostnameValidation) to enable the remediation.
Splunk Enterprise peers in Splunk Enterprise versions before 9.0 and Splunk Cloud Platform versions before 8.2.2203 did not validate the TLS certificates during Splunk-to-Splunk communications by default. Splunk peer communications configured properly with valid certificates were not vulnerable. However, an attacker with administrator credentials could add a peer without a valid certificate and connections from misconfigured nodes without valid certificates did not fail by default. For Splunk Enterprise, update to Splunk Enterprise version 9.0 and Configure TLS host name validation for Splunk-to-Splunk communications (https://docs.splunk.com/Documentation/Splunk/9.0.0/Security/EnableTLSCertHostnameValidation) to enable the remediation.
The httplib and urllib Python libraries that Splunk shipped with Splunk Enterprise did not validate certificates using the certificate authority (CA) certificate stores by default in Splunk Enterprise versions before 9.0 and Splunk Cloud Platform versions before 8.2.2203. Python 3 client libraries now verify server certificates by default and use the appropriate CA certificate stores for each library. Apps and add-ons that include their own HTTP libraries are not affected. For Splunk Enterprise, update to Splunk Enterprise version 9.0 and Configure TLS host name validation for Splunk-to-Splunk communications (https://docs.splunk.com/Documentation/Splunk/9.0.0/Security/EnableTLSCertHostnameValidation) to enable the remediation.
The Monitoring Console app configured in Distributed mode allows for a Reflected XSS in a query parameter in Splunk Enterprise versions before 8.1.4. The Monitoring Console app is a bundled app included in Splunk Enterprise, not for download on SplunkBase, and not installed on Splunk Cloud Platform instances. Note that the Cloud Monitoring Console is not impacted.