Chris Green

**Name of the Vulnerable Software and Affected Versions** Splunk Add-on Builder versions prior to 4.1.2 Splunk CloudConnect SDK versions prior to 3.1.3 **Description** The issue occurs when 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. This affects not only the Splunk Add-on Builder but also apps generated by it when using the REST API Modular Input functionality, as well as potentially third-party apps and add-ons that directly call the `cloudconnectlib.splunktacollectorlib.cloud connect mod input` Python class. **Recommendations** For Splunk Add-on Builder versions prior to 4.1.2, update to version 4.1.2 or later. For Splunk CloudConnect SDK versions prior to 3.1.3, update to version 3.1.3 or later. As a temporary workaround, consider restricting the use of the REST API Modular Input functionality until a patch is applied.

**Name of the Vulnerable Software and Affected Versions** Splunk Enterprise versions prior to 9.0 Splunk Cloud Platform versions prior to 8.2.2203 **Description** The issue concerns the lack of TLS certificate validation during Splunk-to-Splunk communications by default in affected versions. This could allow an attacker with administrator credentials to add a peer without a valid certificate. Connections from misconfigured nodes without valid certificates did not fail by default. **Recommendations** For Splunk Enterprise versions prior to 9.0, update to Splunk Enterprise version 9.0. For Splunk Enterprise, configure TLS host name validation for Splunk-to-Splunk communications to enable the remediation. For Splunk Cloud Platform versions prior to 8.2.2203, update to Splunk Cloud Platform version 8.2.2203 or later.

**Name of the Vulnerable Software and Affected Versions** Splunk Enterprise versions prior to 9.0 Splunk Cloud Platform versions prior to 8.2.2203 **Description** The issue concerns the lack of TLS certificate validation during Splunk-to-Splunk communications by default in affected versions. This could allow an attacker with administrator credentials to add a peer without a valid certificate. Connections from misconfigured nodes without valid certificates did not fail by default. **Recommendations** For Splunk Enterprise versions prior to 9.0, update to Splunk Enterprise version 9.0. For Splunk Enterprise, configure TLS host name validation for Splunk-to-Splunk communications to enable remediation. For Splunk Cloud Platform versions prior to 8.2.2203, update to Splunk Cloud Platform version 8.2.2203 or later.

**Name of the Vulnerable Software and Affected Versions** Splunk Enterprise versions prior to 9.0 Splunk Cloud Platform versions prior to 8.2.2203 **Description** The issue concerns the httplib and urllib Python libraries in Splunk, which did not validate certificates using the certificate authority (CA) certificate stores by default. This has been addressed in newer versions where Python 3 client libraries now verify server certificates by default. The estimated number of potentially affected devices is not specified. There is no information about real-world incidents where this issue was exploited. **Recommendations** For Splunk Enterprise versions prior to 9.0, update to Splunk Enterprise version 9.0. For Splunk Enterprise, configure TLS host name validation for Splunk-to-Splunk communications by following the documentation at https://docs.splunk.com/Documentation/Splunk/9.0.0/Security/EnableTLSCertHostnameValidation to enable the remediation. For Splunk Cloud Platform versions prior to 8.2.2203, update to version 8.2.2203 or later.

**Name of the Vulnerable Software and Affected Versions** Universal Forwarder versions prior to 9.0 **Description** The universal forwarder has management services available remotely by default in versions before 9.0, which can introduce a potential exposure if not required. In version 9.0, the management port is bound to localhost by default, preventing remote logins. Customers are recommended to assess the potential severity of this exposure specific to their environment. **Recommendations** For Universal Forwarder versions prior to 9.0, if management services are not required, set `disableDefaultPort` = true in `server.conf` or `allowRemoteLogin` = never in `server.conf` or `mgmtHostPort` = localhost in `web.conf` to disable remote management services.

**Name of the Vulnerable Software and Affected Versions** Splunk Enterprise versions prior to 9.0 **Description** The issue allows an attacker to inject risky search commands into a form token when the token is used in a query in a cross-origin request, bypassing SPL safeguards for risky commands. This is a browser-based attack and cannot be exploited at will. **Recommendations** For versions prior to 9.0, update to version 9.0 or later to resolve the issue. As a temporary workaround, consider limiting access to custom and potentially risky commands using the new capabilities provided in version 9.0.

**Name of the Vulnerable Software and Affected Versions** Splunk Enterprise and Universal Forwarder versions prior to 9.0 **Description** The issue is related to the Splunk command-line interface (CLI) not validating TLS certificates while connecting to a remote Splunk platform instance by default. This requires conditions beyond the control of a potential bad actor, such as a machine-in-the-middle attack, and is rated as a High complexity attack. There is no evidence of exploitation of this issue by external parties at the time of publishing. The Splunk Cloud Platform is not affected. **Recommendations** For Splunk Enterprise and Universal Forwarder versions prior to 9.0, update to version 9.0 and follow the documentation to enable TLS host name validation for the Splunk CLI. This can be done by configuring the settings as described in the Splunk documentation.