CVE Vulnerability Catalog

In Splunk Connect for Kafka versions below 2.2.7, an unauthenticated user who can reach the Kafka Connect REST API could configure a non-secure HTTP Event Collector endpoint in Splunk Enterprise, causing the connector to send authentication credentials to an attacker-controlled server. This could lead to credential exposure and compromise of data sent through the connector.

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.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 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, 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 Splunk SOAR versions below 8.6.0, an unauthenticated user who can observe or alter network traffic between Splunk SOAR and a configured CyberArk REST server could access or modify all relevant data exchanged through that credential manager. The vulnerability exists because the CyberArk REST client does not verify server certificates by default. The attack requires network-path interception capability between Splunk SOAR and the CyberArk REST server.

In Splunk SOAR versions below 8.6.0, an authenticated user with no role assigned could submit a crafted file path to the REST API and execute arbitrary code. The vulnerability exists because the REST API does not require an assigned role for the request and does not restrict the user-supplied file path to the intended temporary directory.

In Splunk SOAR versions below 8.6.0, an unauthenticated user could spoof the source IP address in a crafted request to an Automation Broker notification endpoint and execute arbitrary code on the Splunk SOAR host. The vulnerability exists because the Splunk SOAR Automation Broker trusts a client-supplied source IP address header as proof that the request originates from the local system. Successful exploitation can expose all relevant data, affect system integrity, and disrupt service availability.

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" 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, and Splunk Secure Gateway versions below 3.10.9, 3.9.23, and 3.8.70, a user who does not hold the "admin" or "power" Splunk roles could use crafted report notification data to cause Splunk Secure Gateway to send a request to the Splunk Enterprise REST API using a system-level session token and modify the Splunk platform configuration. The user could then obtain a session token without a password and use it to access all relevant data and affect system integrity. The vulnerability exists because Splunk Secure Gateway does not validate decoded report notification identifiers before using them to construct requests to the Splunk Enterprise REST API.

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