CVSS: 8.1EPSS: 0%CPEs: 2EXPL: 0CVE-2022-32154 – Risky commands warnings in Splunk Enterprise Dashboards
https://notcve.org/view.php?id=CVE-2022-32154
Dashboards in Splunk Enterprise versions before 9.0 might let an attacker inject risky search commands into a form token when the token is used in a query in a cross-origin request. The result bypasses SPL safeguards for risky commands. See New capabilities can limit access to some custom and potentially risky commands (https://docs.splunk.com/Documentation/Splunk/9.0.0/Security/SPLsafeguards#New_capabilities_can_limit_access_to_some_custom_and_potentially_risky_commands) for more information. Note that the attack is browser-based and an attacker cannot exploit it at will. Los cuadros de mando en Splunk Enterprise versiones anteriores a 9.0, podrían permitir a un atacante inyectar comandos de búsqueda arriesgados en un token de formulario cuando el token es usado en una consulta en una petición de origen cruzado. • https://docs.splunk.com/Documentation/Splunk/9.0.0/Security/SPLsafeguards#New_capabilities_can_limit_access_to_some_custom_and_potentially_risky_commands https://docs.splunk.com/Documentation/Splunk/9.0.0/Security/Updates https://research.splunk.com/application/splunk_command_and_scripting_interpreter_delete_usage https://research.splunk.com/application/splunk_command_and_scripting_interpreter_risky_commands https://research.splunk.com/application/splunk_command_and_scripting_interpreter_risky_spl_mltk https://www.splunk.c • CWE-20: Improper Input Validation CWE-77: Improper Neutralization of Special Elements used in a Command ('Command Injection') •
CVSS: 8.1EPSS: 0%CPEs: 2EXPL: 0CVE-2022-32153 – Splunk Enterprise lacked TLS host name validation
https://notcve.org/view.php?id=CVE-2022-32153
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. Los peers de Splunk Enterprise en las versiones de Splunk Enterprise anteriores a la 9.0 y las versiones de Splunk Cloud Platform anteriores a la 8.2.2203 no comprueban los certificados TLS durante las comunicaciones de Splunk a Splunk por defecto. • https://docs.splunk.com/Documentation/Splunk/9.0.0/Security/EnableTLSCertHostnameValidation https://docs.splunk.com/Documentation/Splunk/9.0.0/Security/Updates https://research.splunk.com/application/splunk_digital_certificates_infrastructure_version https://research.splunk.com/application/splunk_digital_certificates_lack_of_encryption https://research.splunk.com/application/splunk_protocol_impersonation_weak_encryption_selfsigned https://research.splunk.com/network/splunk_identified_ssl_tls_certificates https://www.splunk.com/en_ • CWE-295: Improper Certificate Validation CWE-297: Improper Validation of Certificate with Host Mismatch •
CVSS: 8.1EPSS: 0%CPEs: 2EXPL: 0CVE-2022-32152 – Splunk Enterprise lacked TLS cert validation for Splunk-to-Splunk communication by default
https://notcve.org/view.php?id=CVE-2022-32152
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. Los peers de Splunk Enterprise en Splunk Enterprise versiones anteriores a 9.0 y Splunk Cloud Platform versiones anteriores a 8.2.2203 no comprueban los certificados TLS durante las comunicaciones de Splunk a Splunk por defecto. • https://docs.splunk.com/Documentation/Splunk/9.0.0/Security/EnableTLSCertHostnameValidation https://docs.splunk.com/Documentation/Splunk/9.0.0/Security/Updates https://research.splunk.com/application/splunk_digital_certificates_infrastructure_version https://research.splunk.com/application/splunk_digital_certificates_lack_of_encryption https://research.splunk.com/application/splunk_protocol_impersonation_weak_encryption_selfsigned https://research.splunk.com/network/splunk_identified_ssl_tls_certificates https://www.splunk.com/en_ • CWE-295: Improper Certificate Validation •
CVSS: 9.1EPSS: 0%CPEs: 2EXPL: 0CVE-2022-32151 – Splunk Enterprise disabled TLS validation using the CA certificate stores in Python 3 libraries by default
https://notcve.org/view.php?id=CVE-2022-32151
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. Las bibliotecas de Python httplib y urllib que Splunk envió con Splunk Enterprise no comprueban los certificados usando los almacenes de certificados de la autoridad de certificación (CA) de forma predeterminada en Splunk Enterprise versiones anteriores a 9.0 y Splunk Cloud Platform versiones anteriores a 8.2.2203. • https://docs.splunk.com/Documentation/Splunk/9.0.0/Security/EnableTLSCertHostnameValidation https://docs.splunk.com/Documentation/Splunk/9.0.0/Security/Updates https://research.splunk.com/application/splunk_protocol_impersonation_weak_encryption_simplerequest https://www.splunk.com/en_us/product-security/announcements/svd-2022-0601.html • CWE-295: Improper Certificate Validation •
CVSS: 9.1EPSS: 0%CPEs: 29EXPL: 1CVE-2021-22945
https://notcve.org/view.php?id=CVE-2021-22945
When sending data to an MQTT server, libcurl <= 7.73.0 and 7.78.0 could in some circumstances erroneously keep a pointer to an already freed memory area and both use that again in a subsequent call to send data and also free it *again*. Cuando se envían datos a un servidor MQTT, libcurl versiones anteriores a 7.73.0, incluyéndola y 7.78.0, podría en algunas circunstancias, mantener erróneamente un puntero a un área de memoria ya liberada y usarlo de nuevo en una llamada posterior para enviar datos y también liberarlo *de nuevo* • http://seclists.org/fulldisclosure/2022/Mar/29 https://cert-portal.siemens.com/productcert/pdf/ssa-389290.pdf https://hackerone.com/reports/1269242 https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/APOAK4X73EJTAPTSVT7IRVDMUWVXNWGD https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/RWLEC6YVEM2HWUBX67SDGPSY4CQB72OE https://security.gentoo.org/glsa/202212-01 https://security.netapp.com/advisory/ntap-20211029-0003 https://support.apple.com& • CWE-415: Double Free •