Total
29480 CVE
| CVE | Vendors | Products | Updated | CVSS v2 | CVSS v3 |
|---|---|---|---|---|---|
| CVE-2024-3454 | 1 Csa-iot | 1 Matter | 2024-11-21 | N/A | 3.5 LOW |
| An implementation issue in the Connectivity Standards Alliance Matter 1.2 protocol as used in the connectedhomeip SDK allows a third party to disclose information about devices part of the same fabric (footprinting), even though the protocol is designed to prevent access to such information. | |||||
| CVE-2024-3297 | 1 Csa-iot | 1 Matter | 2024-11-21 | N/A | 6.5 MEDIUM |
| An issue in the Certificate Authenticated Session Establishment (CASE) protocol for establishing secure sessions between two devices, as implemented in the Matter protocol versions before Matter 1.1 allows an attacker to replay manipulated CASE Sigma1 messages to make the device unresponsive until the device is power-cycled. | |||||
| CVE-2024-3228 | 1 Wpkube | 1 Kiwi Social Share | 2024-11-21 | N/A | 5.3 MEDIUM |
| The Social Sharing Plugin – Kiwi plugin for WordPress is vulnerable to Information Exposure in all versions up to, and including, 2.1.7 via the 'kiwi-nw-pinterest' class. This makes it possible for unauthenticated attackers to view limited content from password protected posts. | |||||
| CVE-2024-3175 | 1 Google | 1 Chrome | 2024-11-21 | N/A | 6.3 MEDIUM |
| Insufficient data validation in Extensions in Google Chrome prior to 120.0.6099.62 allowed a remote attacker to perform privilege escalation via a crafted Chrome Extension. (Chromium security severity: Low) | |||||
| CVE-2024-3174 | 1 Google | 1 Chrome | 2024-11-21 | N/A | 8.8 HIGH |
| Inappropriate implementation in V8 in Google Chrome prior to 119.0.6045.105 allowed a remote attacker to potentially exploit object corruption via a crafted HTML page. (Chromium security severity: High) | |||||
| CVE-2024-3172 | 1 Google | 1 Chrome | 2024-11-21 | N/A | 8.8 HIGH |
| Insufficient data validation in DevTools in Google Chrome prior to 121.0.6167.85 allowed a remote attacker who convinced a user to engage in specific UI gestures to execute arbitrary code via a crafted HTML page. (Chromium security severity: High) | |||||
| CVE-2024-3156 | 1 Google | 1 Chrome | 2024-11-21 | N/A | 8.8 HIGH |
| Inappropriate implementation in V8 in Google Chrome prior to 123.0.6312.105 allowed a remote attacker to potentially perform out of bounds memory access via a crafted HTML page. (Chromium security severity: High) | |||||
| CVE-2024-3073 | 1 Wp-ecommerce | 1 Easy Wp Smtp | 2024-11-21 | N/A | 2.7 LOW |
| The Easy WP SMTP by SendLayer – WordPress SMTP and Email Log Plugin plugin for WordPress is vulnerable to information exposure in all versions up to, and including, 2.3.0. This is due to plugin providing the SMTP password in the SMTP Password field when viewing the settings. This makes it possible for authenticated attackers, with administrative-level access and above, to view the SMTP password for the supplied server. Although this would not be useful for attackers in most cases, if an administrator account becomes compromised this could be useful information to an attacker in a limited environment. | |||||
| CVE-2024-39870 | 1 Siemens | 1 Sinema Remote Connect Server | 2024-11-21 | N/A | 6.3 MEDIUM |
| A vulnerability has been identified in SINEMA Remote Connect Server (All versions < V3.2 SP1). The affected applications can be configured to allow users to manage own users. A local authenticated user with this privilege could use this modify users outside of their own scope as well as to escalate privileges. | |||||
| CVE-2024-39869 | 1 Siemens | 1 Sinema Remote Connect Server | 2024-11-21 | N/A | 6.5 MEDIUM |
| A vulnerability has been identified in SINEMA Remote Connect Server (All versions < V3.2 SP1). Affected products allow to upload certificates. An authenticated attacker could upload a crafted certificates leading to a permanent denial-of-service situation. In order to recover from such an attack, the offending certificate needs to be removed manually. | |||||
| CVE-2024-39807 | 1 Mattermost | 1 Mattermost | 2024-11-21 | N/A | 3.1 LOW |
| Mattermost versions 9.5.x <= 9.5.5 and 9.8.0 fail to properly sanitize the recipients of a webhook event which allows an attacker monitoring webhook events to retrieve the channel IDs of archived or restored channels. | |||||
| CVE-2024-39740 | 1 Ibm | 2 Datacap, Datacap Navigator | 2024-11-21 | N/A | 4.3 MEDIUM |
| IBM Datacap Navigator 9.1.5, 9.1.6, 9.1.7, 9.1.8, and 9.1.9 displays version information in HTTP requests that could allow an attacker to gather information for future attacks against the system. IBM X-Force ID: 296009. | |||||
| CVE-2024-39729 | 1 Ibm | 2 Datacap, Datacap Navigator | 2024-11-21 | N/A | 4.3 MEDIUM |
| IBM Datacap Navigator 9.1.5, 9.1.6, 9.1.7, 9.1.8, and 9.1.9 could allow an authenticated user to obtain sensitive information from source code that could be used in further attacks against the system. IBM X-Force ID: 295968. | |||||
| CVE-2024-39676 | 1 Apache | 1 Pinot | 2024-11-21 | N/A | 7.5 HIGH |
| Exposure of Sensitive Information to an Unauthorized Actor vulnerability in Apache Pinot. This issue affects Apache Pinot: from 0.1 before 1.0.0. Users are recommended to upgrade to version 1.0.0 and configure RBAC, which fixes the issue. Details: When using a request to path “/appconfigs” to the controller, it can lead to the disclosure of sensitive information such as system information (e.g. arch, os version), environment information (e.g. maxHeapSize) and Pinot configurations (e.g. zookeeper path). This issue was addressed by the Role-based Access Control https://docs.pinot.apache.org/operators/tutorials/authentication/basic-auth-access-control , so that /appConfigs` and all other APIs can be access controlled. Only authorized users have access to it. Note the user needs to add the admin role accordingly to the RBAC guide to control access to this endpoint, and in the future version of Pinot, a default admin role is planned to be added. | |||||
| CVE-2024-39674 | 1 Huawei | 2 Emui, Harmonyos | 2024-11-21 | N/A | 6.2 MEDIUM |
| Plaintext vulnerability in the Gallery search module. Impact: Successful exploitation of this vulnerability will affect availability. | |||||
| CVE-2024-39673 | 1 Huawei | 2 Emui, Harmonyos | 2024-11-21 | N/A | 6.8 MEDIUM |
| Vulnerability of serialisation/deserialisation mismatch in the iAware module. Impact: Successful exploitation of this vulnerability may affect service confidentiality. | |||||
| CVE-2024-39672 | 1 Huawei | 2 Emui, Harmonyos | 2024-11-21 | N/A | 8.4 HIGH |
| Memory request logic vulnerability in the memory module. Impact: Successful exploitation of this vulnerability will affect integrity and availability. | |||||
| CVE-2024-39670 | 1 Huawei | 2 Emui, Harmonyos | 2024-11-21 | N/A | 6.2 MEDIUM |
| Privilege escalation vulnerability in the account synchronisation module. Impact: Successful exploitation of this vulnerability will affect availability. | |||||
| CVE-2024-39593 | 1 Sap | 1 Landscape Management | 2024-11-21 | N/A | 6.9 MEDIUM |
| SAP Landscape Management allows an authenticated user to read confidential data disclosed by the REST Provider Definition response. Successful exploitation can cause high impact on confidentiality of the managed entities. | |||||
| CVE-2024-39483 | 1 Linux | 1 Linux Kernel | 2024-11-21 | N/A | 5.5 MEDIUM |
| In the Linux kernel, the following vulnerability has been resolved: KVM: SVM: WARN on vNMI + NMI window iff NMIs are outright masked When requesting an NMI window, WARN on vNMI support being enabled if and only if NMIs are actually masked, i.e. if the vCPU is already handling an NMI. KVM's ABI for NMIs that arrive simultanesouly (from KVM's point of view) is to inject one NMI and pend the other. When using vNMI, KVM pends the second NMI simply by setting V_NMI_PENDING, and lets the CPU do the rest (hardware automatically sets V_NMI_BLOCKING when an NMI is injected). However, if KVM can't immediately inject an NMI, e.g. because the vCPU is in an STI shadow or is running with GIF=0, then KVM will request an NMI window and trigger the WARN (but still function correctly). Whether or not the GIF=0 case makes sense is debatable, as the intent of KVM's behavior is to provide functionality that is as close to real hardware as possible. E.g. if two NMIs are sent in quick succession, the probability of both NMIs arriving in an STI shadow is infinitesimally low on real hardware, but significantly larger in a virtual environment, e.g. if the vCPU is preempted in the STI shadow. For GIF=0, the argument isn't as clear cut, because the window where two NMIs can collide is much larger in bare metal (though still small). That said, KVM should not have divergent behavior for the GIF=0 case based on whether or not vNMI support is enabled. And KVM has allowed simultaneous NMIs with GIF=0 for over a decade, since commit 7460fb4a3400 ("KVM: Fix simultaneous NMIs"). I.e. KVM's GIF=0 handling shouldn't be modified without a *really* good reason to do so, and if KVM's behavior were to be modified, it should be done irrespective of vNMI support. | |||||