Export limit exceeded: 10842 CVEs match your query. Please refine your search to export 10,000 CVEs or fewer.
Export limit exceeded: 338064 CVEs match your query. Please refine your search to export 10,000 CVEs or fewer.
Search
Search Results (338064 CVEs found)
| CVE | Vendors | Products | Updated | CVSS v3.1 |
|---|---|---|---|---|
| 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-2022-22939 | 1 Vmware | 1 Cloud Foundation | 2025-10-31 | 4.9 Medium |
| VMware Cloud Foundation contains an information disclosure vulnerability due to logging of credentials in plain-text within multiple log files on the SDDC Manager. A malicious actor with root access on VMware Cloud Foundation SDDC Manager may be able to view credentials in plaintext within one or more log files. | ||||
| CVE-2021-21995 | 1 Vmware | 2 Cloud Foundation, Esxi | 2025-10-31 | 7.5 High |
| OpenSLP as used in ESXi has a denial-of-service vulnerability due a heap out-of-bounds read issue. A malicious actor with network access to port 427 on ESXi may be able to trigger a heap out-of-bounds read in OpenSLP service resulting in a denial-of-service condition. | ||||
| CVE-2021-21994 | 1 Vmware | 2 Cloud Foundation, Esxi | 2025-10-31 | 9.8 Critical |
| SFCB (Small Footprint CIM Broker) as used in ESXi has an authentication bypass vulnerability. A malicious actor with network access to port 5989 on ESXi may exploit this issue to bypass SFCB authentication by sending a specially crafted request. | ||||
| 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-2025-10348 | 1 Urve | 1 Urve | 2025-10-31 | N/A |
| URVE Smart Office is vulnerable to Stored XSS in report problem functionality. An attacker with a low-privileged account can upload an SVG file containing a malicious payload, which will be executed when a victim visits the URL of the uploaded resource. The resource is available to anyone without any form of authentication. This issue was fixed in version 1.1.24. | ||||
| CVE-2025-10317 | 1 Opensolution | 1 Quick.cart | 2025-10-31 | N/A |
| Quick.Cart is vulnerable to Cross-Site Request Forgery in product creation functionality. Malicious attacker can craft special website, which when visited by the admin, will automatically send a POST request creating a malicious product with content defined by the attacker. This software does not implement any protection against this type of attack. All forms available in this software are potentially vulnerable. The vendor was notified early about this vulnerability, but didn't respond with the details of vulnerability or vulnerable version range. Only version 6.7 was tested and confirmed as vulnerable, other versions were not tested and might also be vulnerable. | ||||
| CVE-2025-7329 | 1 Rockwellautomation | 2 1783-natr, 1783-natr Firmware | 2025-10-30 | 4.8 Medium |
| A Stored Cross-Site Scripting security issue exists in the affected product that could potentially allow a malicious user to view and modify sensitive data or make the webpage unavailable. The vulnerability stems from missing special character filtering and encoding. Successful exploitation requires an attacker to be able to update configuration fields behind admin login. | ||||
| CVE-2025-7330 | 1 Rockwellautomation | 2 1783-natr, 1783-natr Firmware | 2025-10-30 | 6.5 Medium |
| A cross-site request forgery security issue exists in the product and version listed. The vulnerability stems from missing CSRF checks on the impacted form. This allows for unintended configuration modification if an attacker can convince a logged in admin to visit a crafted link. | ||||
| CVE-2025-21801 | 1 Linux | 1 Linux Kernel | 2025-10-30 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: net: ravb: Fix missing rtnl lock in suspend/resume path Fix the suspend/resume path by ensuring the rtnl lock is held where required. Calls to ravb_open, ravb_close and wol operations must be performed under the rtnl lock to prevent conflicts with ongoing ndo operations. Without this fix, the following warning is triggered: [ 39.032969] ============================= [ 39.032983] WARNING: suspicious RCU usage [ 39.033019] ----------------------------- [ 39.033033] drivers/net/phy/phy_device.c:2004 suspicious rcu_dereference_protected() usage! ... [ 39.033597] stack backtrace: [ 39.033613] CPU: 0 UID: 0 PID: 174 Comm: python3 Not tainted 6.13.0-rc7-next-20250116-arm64-renesas-00002-g35245dfdc62c #7 [ 39.033623] Hardware name: Renesas SMARC EVK version 2 based on r9a08g045s33 (DT) [ 39.033628] Call trace: [ 39.033633] show_stack+0x14/0x1c (C) [ 39.033652] dump_stack_lvl+0xb4/0xc4 [ 39.033664] dump_stack+0x14/0x1c [ 39.033671] lockdep_rcu_suspicious+0x16c/0x22c [ 39.033682] phy_detach+0x160/0x190 [ 39.033694] phy_disconnect+0x40/0x54 [ 39.033703] ravb_close+0x6c/0x1cc [ 39.033714] ravb_suspend+0x48/0x120 [ 39.033721] dpm_run_callback+0x4c/0x14c [ 39.033731] device_suspend+0x11c/0x4dc [ 39.033740] dpm_suspend+0xdc/0x214 [ 39.033748] dpm_suspend_start+0x48/0x60 [ 39.033758] suspend_devices_and_enter+0x124/0x574 [ 39.033769] pm_suspend+0x1ac/0x274 [ 39.033778] state_store+0x88/0x124 [ 39.033788] kobj_attr_store+0x14/0x24 [ 39.033798] sysfs_kf_write+0x48/0x6c [ 39.033808] kernfs_fop_write_iter+0x118/0x1a8 [ 39.033817] vfs_write+0x27c/0x378 [ 39.033825] ksys_write+0x64/0xf4 [ 39.033833] __arm64_sys_write+0x18/0x20 [ 39.033841] invoke_syscall+0x44/0x104 [ 39.033852] el0_svc_common.constprop.0+0xb4/0xd4 [ 39.033862] do_el0_svc+0x18/0x20 [ 39.033870] el0_svc+0x3c/0xf0 [ 39.033880] el0t_64_sync_handler+0xc0/0xc4 [ 39.033888] el0t_64_sync+0x154/0x158 [ 39.041274] ravb 11c30000.ethernet eth0: Link is Down | ||||
| CVE-2018-0197 | 1 Cisco | 2 Ios, Ios Xe | 2025-10-30 | 6.5 Medium |
| A vulnerability in the VLAN Trunking Protocol (VTP) subsystem of Cisco IOS Software and Cisco IOS XE Software could allow an unauthenticated, adjacent attacker to corrupt the internal VTP database on an affected device and cause a denial of service (DoS) condition. The vulnerability is due to a logic error in how the affected software handles a subset of VTP packets. An attacker could exploit this vulnerability by sending VTP packets in a sequence that triggers a timeout in the VTP message processing code of the affected software. A successful exploit could allow the attacker to impact the ability to create, modify, or delete VLANs and cause a DoS condition. There are workarounds that address this vulnerability. This vulnerability affects Cisco devices that are running a vulnerable release of Cisco IOS Software or Cisco IOS XE Software, are operating in VTP client mode or VTP server mode, and do not have a VTP domain name configured. The default configuration for Cisco devices that are running Cisco IOS Software or Cisco IOS XE Software and support VTP is to operate in VTP server mode with no domain name configured. | ||||
| CVE-2021-34770 | 1 Cisco | 11 Catalyst 9800, Catalyst 9800-40, Catalyst 9800-40 Wireless Controller and 8 more | 2025-10-30 | 10 Critical |
| A vulnerability in the Control and Provisioning of Wireless Access Points (CAPWAP) protocol processing of Cisco IOS XE Software for Cisco Catalyst 9000 Family Wireless Controllers could allow an unauthenticated, remote attacker to execute arbitrary code with administrative privileges or cause a denial of service (DoS) condition on an affected device. The vulnerability is due to a logic error that occurs during the validation of CAPWAP packets. An attacker could exploit this vulnerability by sending a crafted CAPWAP packet to an affected device. A successful exploit could allow the attacker to execute arbitrary code with administrative privileges or cause the affected device to crash and reload, resulting in a DoS condition. | ||||
| CVE-2025-61234 | 1 Paytef | 1 Dataphone A920 | 2025-10-30 | 7.5 High |
| Incorrect access control on Dataphone A920 v2025.07.161103 exposes a service on port 8888 by default on the local network without authentication. This allows an attacker to interact with the device via a TCP socket without credentials. Additionally, sending an HTTP request to the service on port 8888 triggers an error in the response, which exposes the functionality, headers identifying Paytef dataphone packets, and the build version. | ||||
| CVE-2025-60595 | 1 Sphengineering | 1 Ugcs | 2025-10-30 | 8.2 High |
| SPH Engineering UgCS 5.13.0 is vulnerable to Arbitary code execution. | ||||
| CVE-2025-60542 | 1 Typeorm | 1 Typeorm | 2025-10-30 | 6.5 Medium |
| SQL Injection vulnerability in TypeORM before 0.3.26 via crafted request to repository.save or repository.update due to the sqlstring call using stringifyObjects default to false. | ||||
| CVE-2021-34705 | 1 Cisco | 2 Ios, Ios Xe | 2025-10-30 | 5.3 Medium |
| A vulnerability in the Voice Telephony Service Provider (VTSP) service of Cisco IOS Software and Cisco IOS XE Software could allow an unauthenticated, remote attacker to bypass configured destination patterns and dial arbitrary numbers. This vulnerability is due to insufficient validation of dial strings at Foreign Exchange Office (FXO) interfaces. An attacker could exploit this vulnerability by sending a malformed dial string to an affected device via either the ISDN protocol or SIP. A successful exploit could allow the attacker to conduct toll fraud, resulting in unexpected financial impact to affected customers. | ||||
| CVE-2021-34767 | 1 Cisco | 9 Catalyst 9800, Catalyst 9800-40, Catalyst 9800-80 and 6 more | 2025-10-30 | 7.4 High |
| A vulnerability in IPv6 traffic processing of Cisco IOS XE Wireless Controller Software for Cisco Catalyst 9000 Family Wireless Controllers could allow an unauthenticated, adjacent attacker to cause a Layer 2 (L2) loop in a configured VLAN, resulting in a denial of service (DoS) condition for that VLAN. The vulnerability is due to a logic error when processing specific link-local IPv6 traffic. An attacker could exploit this vulnerability by sending a crafted IPv6 packet that would flow inbound through the wired interface of an affected device. A successful exploit could allow the attacker to cause traffic drops in the affected VLAN, thus triggering the DoS condition. | ||||
| CVE-2025-20169 | 1 Cisco | 2 Ios, Ios Xe | 2025-10-30 | 7.7 High |
| A vulnerability in the SNMP subsystem of Cisco IOS Software and Cisco IOS XE Software could allow an authenticated, remote attacker to cause a DoS condition on an affected device. This vulnerability is due to improper error handling when parsing SNMP requests. An attacker could exploit this vulnerability by sending a crafted SNMP request to an affected device. A successful exploit could allow the attacker to cause the device to reload unexpectedly, resulting in a DoS condition. This vulnerability affects SNMP versions 1, 2c, and 3. To exploit this vulnerability through SNMP v2c or earlier, the attacker must know a valid read-write or read-only SNMP community string for the affected system. To exploit this vulnerability through SNMP v3, the attacker must have valid SNMP user credentials for the affected system. | ||||
| CVE-2025-8851 | 1 Libtiff | 1 Libtiff | 2025-10-30 | 5.3 Medium |
| A vulnerability was determined in LibTIFF up to 4.5.1. Affected by this issue is the function readSeparateStripsetoBuffer of the file tools/tiffcrop.c of the component tiffcrop. The manipulation leads to stack-based buffer overflow. Local access is required to approach this attack. The patch is identified as 8a7a48d7a645992ca83062b3a1873c951661e2b3. It is recommended to apply a patch to fix this issue. | ||||
| 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--- | ||||