CVE Vulnerability Catalog

In Splunk AI Toolkit versions below 6.0.1, a user with the "power" role could modify app-provided scheduled searches to run arbitrary SPL using the permissions of the search owner. This could allow access to all relevant data and affect system integrity.

In Splunk AI Toolkit versions below 6.0.1, a user who does not hold the "admin" or "power" Splunk roles could delete the experiment history of another user without permission through the REST API. The vulnerability is possible because Splunk AI Toolkit deletes experiment history before it verifies that the user can delete the associated experiment.

In Splunk AI Toolkit versions below 6.0.0, a user with the "power" role could access and delete all relevant data in experiment history, including data associated with other users. The vulnerability is due to not preserving the trusted experiment scope when processing caller-controlled query values.

In Splunk AI Toolkit versions below 6.0.0, a user with a role having the schedule_search capability could cause a scheduled search to load and deserialize a model file through the apply search command. The vulnerability is due to the apply search command not being marked as risky.

In Splunk AI Toolkit versions below 6.0.0, a user with the "power" role could execute arbitrary code on the Splunk server by loading a model file containing crafted sparse matrix data. The vulnerability is due to deserialization of untrusted data without guarding against embedded pickle content.

In Splunk AI Toolkit versions below 6.0.0, a low-privileged user without "admin" or "power" roles could start, stop, and configure containers, and read or modify connection and configuration data through the REST API. The vulnerability is due to missing authorization checks in multiple REST API handlers.

In Splunk AI Toolkit versions below 6.0.0, a user who can upload models could overwrite a model being uploaded by another user by sending a concurrent upload request for the same model name, causing the resulting model lookup entry to reference attacker-controlled content. The race condition is possible because Splunk AI Toolkit does not verify that the uploaded content belongs to the request that creates the model lookup entry.

In Splunk AI Toolkit versions below 6.0.0, a user who does not hold the "admin" or "power" Splunk roles could obtain predictable or default credentials for connected container services. The use of hard-coded credentials is possible because Splunk AI Toolkit generates or stores credentials for connected container services using predictable or hard-coded default values.

In Splunk AI Toolkit versions below 6.0.0, a user without "admin" or "power" roles could run searches with system-level privileges, access all relevant data, affect system integrity, and read or delete search jobs belonging to other users through Agent Run History. The vulnerability is due to replacing the calling user session key with a system authentication token before performing search operations.

In Cisco Talos Intelligence for Enterprise Security Cloud versions below 1.0.3, an unauthenticated user could access the add-on OpenAPI specification through Splunk Web static file paths. The exposed specification could allow for reconnaissance of the add-on REST API endpoints and authentication model.

In Cisco Talos Intelligence for Enterprise Security Cloud versions below 1.0.3, a user with the get_talos_enrichment capability could send a crafted request to the Talos intelligence enrichment REST API endpoint and cause the instance to make an outbound request to an attacker-controlled server. The request could expose tokens that compromise all relevant data and system integrity in the Splunk instance.

In Splunk Enterprise Security versions below 8.6.1, a user with the ess_analyst role could change UEBA search macros that scheduled searches run with administrator permissions, allowing for access to all relevant data and system integrity through those searches. The vulnerability is due to granting analyst roles write access to search macros that should be writable only by administrator roles.

In Splunk Enterprise Security versions below 8.6.1, a user with a role containing the mc_investigation_read capability could inject SPL through Analyst Queue search filters, allowing for access to all relevant data and system integrity available to the scheduled searches that run for that user. The vulnerability is due to lack of validation of filter field names before they are included in SPL searches.

In versions below 3.2.2 of the Zoom app for Splunk SOAR, a user who holds a role with permission to run actions could expose meeting and personal meeting ID passwords by invoking one of the create meeting, update meeting, or update user settings actions, because the affected password and pmi_password parameters are not masked and are shown in cleartext in the user interface.

In versions below 2.1.4 of the Venafi app for Splunk SOAR, a user who holds a role with permission to run actions could expose keystore and private-key passwords by invoking the get certificate action, because the action's keystore_password and password parameters are not masked and are shown in cleartext in the user interface.

In versions below 2.2.1 of the Splunk Attack Analyzer Connector for Splunk SOAR, a user who holds a role with permission to run actions could expose a sensitive archive password by invoking either the detonate file or detonate url action, because the action's archive_password parameter is not masked and is shown in cleartext in the user interface.

In versions below 1.0.5 of the RSA SecurID Authentication Manager app for Splunk SOAR, a user who holds a role with permission to run actions could expose a sensitive token serial by invoking either the enable token or revoke token action, because the action's token_serial parameter is not masked and is shown in cleartext in the user interface.

In versions below 3.8.5 of the Phantom app for Splunk SOAR, a user who holds a role with permission to run actions could expose a sensitive archive password by invoking the deflate item action, because the action's password parameter is not masked and is shown in cleartext in the user interface.

In versions below 1.5.2 of the MS Graph for Active Directory app for Splunk SOAR, a user with permission to run actions could expose a sensitive password by invoking the reset password action, because the temp_password parameter is not masked and is shown in cleartext in the UI. This is possible because the app does not mark the parameter as a password.

In versions below 5.1.3 of the CrowdStrike OAuth API app for Splunk SOAR, a user with permission to run actions could expose a sensitive document password by invoking detonate file or detonate url actions, because the document_password parameter is not masked and is shown in cleartext in the UI. This is possible because the app does not mark the parameter as a password.