| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| 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. |
| In multiple CODESYS products, file download and upload function allows access to internal files in the working directory e.g. firmware files of the PLC. All requests are processed on the controller only if no level 1 password is configured on the controller or if remote attacker has previously successfully authenticated himself to the controller. A successful Attack may lead to a denial of service, change of local files, or drain of confidential Information. User interaction is not required |
| Multiple CODESYS Products are prone to a out-of bounds read or write access. A low privileged remote attacker may craft a request with invalid offset, which can cause an out-of-bounds read or write access, resulting in denial-of-service condition or local memory overwrite, which can lead to a change of local files. User interaction is not required. |
| In multiple CODESYS products, a remote attacker may craft a request which may cause an unexpected sign extension, resulting in a denial-of-service condition or memory overwrite. |
| In multiple CODESYS products, a low privileged remote attacker may craft a request, which may cause a heap-based buffer overflow, resulting in a denial-of-service condition or memory overwrite. User interaction is not required. |
| Arox School ERP Pro v1.0 was discovered to contain multiple arbitrary file upload vulnerabilities via the Add Photo function at photogalleries.inc.php and the import staff excel function at 1finance_master.inc.php. |
| Jerryscript v2.4.0 was discovered to contain a stack buffer overflow via the function jerryx_print_unhandled_exception in /util/print.c. |
| Rhonabwy before v1.1.5 was discovered to contain a buffer overflow via the component r_jwe_aesgcm_key_unwrap. This vulnerability allows attackers to cause a Denial of Service (DoS) via a crafted JWE token. |
| MariaDB v10.7 was discovered to contain an use-after-poison in in __interceptor_memset at /libsanitizer/sanitizer_common/sanitizer_common_interceptors.inc. |
| MariaDB v10.5 to v10.7 was discovered to contain a segmentation fault via the component st_select_lex_unit::exclude_level. |
| MariaDB v10.2 to v10.7 was discovered to contain a segmentation fault via the component Exec_time_tracker::get_loops/Filesort_tracker::report_use/filesort. |
| MariaDB v10.2 to v10.7 was discovered to contain a segmentation fault via the component Item_args::walk_args. |
| MariaDB v10.4 to v10.8 was discovered to contain a segmentation fault via the component Item_field::fix_outer_field. |
| MariaDB v10.2 to v10.7 was discovered to contain a segmentation fault via the component Item_func_in::cleanup/Item::cleanup_processor. |
| MariaDB v10.2 to v10.7 was discovered to contain a segmentation fault via the component sub_select. |
| MariaDB v10.2 to v10.6.1 was discovered to contain a segmentation fault via the component Item_subselect::init_expr_cache_tracker. |
| MariaDB v10.5 to v10.7 was discovered to contain an assertion failure at table->get_ref_count() == 0 in dict0dict.cc. |
| MariaDB v10.4 to v10.7 was discovered to contain an use-after-poison in prepare_inplace_add_virtual at /storage/innobase/handler/handler0alter.cc. |
