Export limit exceeded: 35583 CVEs match your query. Please refine your search to export 10,000 CVEs or fewer.
Search
Search Results (35583 CVEs found)
| CVE | Vendors | Products | Updated | CVSS v3.1 |
|---|---|---|---|---|
| CVE-2021-22048 | 1 Vmware | 2 Cloud Foundation, Vcenter Server | 2025-10-31 | 8.8 High |
| The vCenter Server contains a privilege escalation vulnerability in the IWA (Integrated Windows Authentication) authentication mechanism. A malicious actor with non-administrative access to vCenter Server may exploit this issue to elevate privileges to a higher privileged group. | ||||
| CVE-2020-4005 | 1 Vmware | 2 Cloud Foundation, Esxi | 2025-10-31 | 7.8 High |
| VMware ESXi (7.0 before ESXi70U1b-17168206, 6.7 before ESXi670-202011101-SG, 6.5 before ESXi650-202011301-SG) contains a privilege-escalation vulnerability that exists in the way certain system calls are being managed. A malicious actor with privileges within the VMX process only, may escalate their privileges on the affected system. Successful exploitation of this issue is only possible when chained with another vulnerability (e.g. CVE-2020-4004) | ||||
| CVE-2022-31698 | 1 Vmware | 2 Cloud Foundation, Vcenter Server | 2025-10-31 | 5.3 Medium |
| The vCenter Server contains a denial-of-service vulnerability in the content library service. A malicious actor with network access to port 443 on vCenter Server may exploit this issue to trigger a denial-of-service condition by sending a specially crafted header. | ||||
| CVE-2025-21977 | 1 Linux | 1 Linux Kernel | 2025-10-30 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: fbdev: hyperv_fb: Fix hang in kdump kernel when on Hyper-V Gen 2 VMs Gen 2 Hyper-V VMs boot via EFI and have a standard EFI framebuffer device. When the kdump kernel runs in such a VM, loading the efifb driver may hang because of accessing the framebuffer at the wrong memory address. The scenario occurs when the hyperv_fb driver in the original kernel moves the framebuffer to a different MMIO address because of conflicts with an already-running efifb or simplefb driver. The hyperv_fb driver then informs Hyper-V of the change, which is allowed by the Hyper-V FB VMBus device protocol. However, when the kexec command loads the kdump kernel into crash memory via the kexec_file_load() system call, the system call doesn't know the framebuffer has moved, and it sets up the kdump screen_info using the original framebuffer address. The transition to the kdump kernel does not go through the Hyper-V host, so Hyper-V does not reset the framebuffer address like it would do on a reboot. When efifb tries to run, it accesses a non-existent framebuffer address, which traps to the Hyper-V host. After many such accesses, the Hyper-V host thinks the guest is being malicious, and throttles the guest to the point that it runs very slowly or appears to have hung. When the kdump kernel is loaded into crash memory via the kexec_load() system call, the problem does not occur. In this case, the kexec command builds the screen_info table itself in user space from data returned by the FBIOGET_FSCREENINFO ioctl against /dev/fb0, which gives it the new framebuffer location. This problem was originally reported in 2020 [1], resulting in commit 3cb73bc3fa2a ("hyperv_fb: Update screen_info after removing old framebuffer"). This commit solved the problem by setting orig_video_isVGA to 0, so the kdump kernel was unaware of the EFI framebuffer. The efifb driver did not try to load, and no hang occurred. But in 2024, commit c25a19afb81c ("fbdev/hyperv_fb: Do not clear global screen_info") effectively reverted 3cb73bc3fa2a. Commit c25a19afb81c has no reference to 3cb73bc3fa2a, so perhaps it was done without knowing the implications that were reported with 3cb73bc3fa2a. In any case, as of commit c25a19afb81c, the original problem came back again. Interestingly, the hyperv_drm driver does not have this problem because it never moves the framebuffer. The difference is that the hyperv_drm driver removes any conflicting framebuffers *before* allocating an MMIO address, while the hyperv_fb drivers removes conflicting framebuffers *after* allocating an MMIO address. With the "after" ordering, hyperv_fb may encounter a conflict and move the framebuffer to a different MMIO address. But the conflict is essentially bogus because it is removed a few lines of code later. Rather than fix the problem with the approach from 2020 in commit 3cb73bc3fa2a, instead slightly reorder the steps in hyperv_fb so conflicting framebuffers are removed before allocating an MMIO address. Then the default framebuffer MMIO address should always be available, and there's never any confusion about which framebuffer address the kdump kernel should use -- it's always the original address provided by the Hyper-V host. This approach is already used by the hyperv_drm driver, and is consistent with the usage guidelines at the head of the module with the function aperture_remove_conflicting_devices(). This approach also solves a related minor problem when kexec_load() is used to load the kdump kernel. With current code, unbinding and rebinding the hyperv_fb driver could result in the framebuffer moving back to the default framebuffer address, because on the rebind there are no conflicts. If such a move is done after the kdump kernel is loaded with the new framebuffer address, at kdump time it could again have the wrong address. This problem and fix are described in terms of the kdump kernel, but it can also occur ---truncated--- | ||||
| CVE-2019-5418 | 5 Debian, Fedoraproject, Opensuse and 2 more | 8 Debian Linux, Fedora, Leap and 5 more | 2025-10-30 | 7.5 High |
| There is a File Content Disclosure vulnerability in Action View <5.2.2.1, <5.1.6.2, <5.0.7.2, <4.2.11.1 and v3 where specially crafted accept headers can cause contents of arbitrary files on the target system's filesystem to be exposed. | ||||
| CVE-2021-22017 | 1 Vmware | 1 Vcenter Server | 2025-10-30 | 5.3 Medium |
| Rhttproxy as used in vCenter Server contains a vulnerability due to improper implementation of URI normalization. A malicious actor with network access to port 443 on vCenter Server may exploit this issue to bypass proxy leading to internal endpoints being accessed. | ||||
| CVE-2021-1647 | 1 Microsoft | 20 Security Essentials, System Center Endpoint Protection, Windows 10 1507 and 17 more | 2025-10-30 | 7.8 High |
| Microsoft Defender Remote Code Execution Vulnerability | ||||
| CVE-2021-26858 | 1 Microsoft | 1 Exchange Server | 2025-10-30 | 7.8 High |
| Microsoft Exchange Server Remote Code Execution Vulnerability | ||||
| CVE-2021-27059 | 1 Microsoft | 2 Excel, Office | 2025-10-30 | 7.6 High |
| Microsoft Office Remote Code Execution Vulnerability | ||||
| CVE-2021-27085 | 1 Microsoft | 7 Internet Explorer, Windows 10 1803, Windows 10 1809 and 4 more | 2025-10-30 | 8.8 High |
| Internet Explorer Remote Code Execution Vulnerability | ||||
| CVE-2021-31199 | 1 Microsoft | 22 Windows 10 1507, Windows 10 1607, Windows 10 1809 and 19 more | 2025-10-30 | 5.2 Medium |
| Microsoft Enhanced Cryptographic Provider Elevation of Privilege Vulnerability | ||||
| CVE-2021-31201 | 1 Microsoft | 22 Windows 10 1507, Windows 10 1607, Windows 10 1809 and 19 more | 2025-10-30 | 5.2 Medium |
| Microsoft Enhanced Cryptographic Provider Elevation of Privilege Vulnerability | ||||
| CVE-2025-11634 | 2 Furbo, Tomofun | 6 Furbo 360 Dog Camera, Furbo 360 Dog Camera Firmware, Furbo Mini and 3 more | 2025-10-30 | 2.4 Low |
| A security flaw has been discovered in Tomofun Furbo 360 and Furbo Mini. This affects an unknown part of the component UART Interface. The manipulation results in information disclosure. An attack on the physical device is feasible. The exploit has been released to the public and may be exploited. The firmware versions determined to be affected are Furbo 360 up to FB0035_FW_036 and Furbo Mini up to MC0020_FW_074. The vendor was contacted early about this disclosure but did not respond in any way. | ||||
| CVE-2025-21952 | 1 Linux | 1 Linux Kernel | 2025-10-30 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: HID: corsair-void: Update power supply values with a unified work handler corsair_void_process_receiver can be called from an interrupt context, locking battery_mutex in it was causing a kernel panic. Fix it by moving the critical section into its own work, sharing this work with battery_add_work and battery_remove_work to remove the need for any locking | ||||
| CVE-2021-31955 | 1 Microsoft | 11 Windows 10 1809, Windows 10 1909, Windows 10 2004 and 8 more | 2025-10-30 | 5.5 Medium |
| Windows Kernel Information Disclosure Vulnerability | ||||
| CVE-2021-33739 | 1 Microsoft | 10 Windows 10 1809, Windows 10 1909, Windows 10 2004 and 7 more | 2025-10-30 | 8.4 High |
| Microsoft DWM Core Library Elevation of Privilege Vulnerability | ||||
| CVE-2022-41080 | 1 Microsoft | 1 Exchange Server | 2025-10-30 | 8.8 High |
| Microsoft Exchange Server Elevation of Privilege Vulnerability | ||||
| CVE-2022-41091 | 1 Microsoft | 18 Windows 10 1507, Windows 10 1607, Windows 10 1809 and 15 more | 2025-10-30 | 5.4 Medium |
| Windows Mark of the Web Security Feature Bypass Vulnerability | ||||
| CVE-2022-41049 | 1 Microsoft | 18 Windows 10 1507, Windows 10 1607, Windows 10 1809 and 15 more | 2025-10-30 | 5.4 Medium |
| Windows Mark of the Web Security Feature Bypass Vulnerability | ||||
| CVE-2022-24521 | 1 Microsoft | 25 Windows 10 1507, Windows 10 1607, Windows 10 1809 and 22 more | 2025-10-30 | 7.8 High |
| Windows Common Log File System Driver Elevation of Privilege Vulnerability | ||||