Total
12744 CVE
| CVE | Vendors | Products | Updated | CVSS v3.1 |
|---|---|---|---|---|
| CVE-2025-43253 | 1 Apple | 3 Macos, Macos Sequoia, Macos Sonoma | 2025-11-03 | 9.8 Critical |
| This issue was addressed with improved input validation. This issue is fixed in macOS Sequoia 15.6, macOS Sonoma 14.7.7. A malicious app may be able to launch arbitrary binaries on a trusted device. | ||||
| CVE-2025-43234 | 1 Apple | 8 Ios, Ipados, Iphone Os and 5 more | 2025-11-03 | 9.8 Critical |
| Multiple memory corruption issues were addressed with improved input validation. This issue is fixed in watchOS 11.6, iOS 18.6 and iPadOS 18.6, tvOS 18.6, macOS Sequoia 15.6, visionOS 2.6. Processing a maliciously crafted texture may lead to unexpected app termination. | ||||
| CVE-2025-43223 | 1 Apple | 10 Ios, Ipados, Iphone Os and 7 more | 2025-11-03 | 7.5 High |
| A denial-of-service issue was addressed with improved input validation. This issue is fixed in macOS Ventura 13.7.7, iPadOS 17.7.9, iOS 18.6 and iPadOS 18.6, macOS Sonoma 14.7.7, watchOS 11.6, macOS Sequoia 15.6, tvOS 18.6, visionOS 2.6. A non-privileged user may be able to modify restricted network settings. | ||||
| CVE-2025-43195 | 1 Apple | 4 Macos, Macos Sequoia, Macos Sonoma and 1 more | 2025-11-03 | 5.5 Medium |
| An issue existed in the handling of environment variables. This issue was addressed with improved validation. This issue is fixed in macOS Sequoia 15.6, macOS Sonoma 14.7.7, macOS Ventura 13.7.7. An app may be able to access sensitive user data. | ||||
| CVE-2025-38009 | 1 Linux | 1 Linux Kernel | 2025-11-03 | 4.7 Medium |
| In the Linux kernel, the following vulnerability has been resolved: wifi: mt76: disable napi on driver removal A warning on driver removal started occurring after commit 9dd05df8403b ("net: warn if NAPI instance wasn't shut down"). Disable tx napi before deleting it in mt76_dma_cleanup(). WARNING: CPU: 4 PID: 18828 at net/core/dev.c:7288 __netif_napi_del_locked+0xf0/0x100 CPU: 4 UID: 0 PID: 18828 Comm: modprobe Not tainted 6.15.0-rc4 #4 PREEMPT(lazy) Hardware name: ASUS System Product Name/PRIME X670E-PRO WIFI, BIOS 3035 09/05/2024 RIP: 0010:__netif_napi_del_locked+0xf0/0x100 Call Trace: <TASK> mt76_dma_cleanup+0x54/0x2f0 [mt76] mt7921_pci_remove+0xd5/0x190 [mt7921e] pci_device_remove+0x47/0xc0 device_release_driver_internal+0x19e/0x200 driver_detach+0x48/0x90 bus_remove_driver+0x6d/0xf0 pci_unregister_driver+0x2e/0xb0 __do_sys_delete_module.isra.0+0x197/0x2e0 do_syscall_64+0x7b/0x160 entry_SYSCALL_64_after_hwframe+0x76/0x7e Tested with mt7921e but the same pattern can be actually applied to other mt76 drivers calling mt76_dma_cleanup() during removal. Tx napi is enabled in their *_dma_init() functions and only toggled off and on again inside their suspend/resume/reset paths. So it should be okay to disable tx napi in such a generic way. Found by Linux Verification Center (linuxtesting.org). | ||||
| CVE-2025-33043 | 1 Ami | 1 Aptio V | 2025-11-03 | 5.8 Medium |
| APTIOV contains a vulnerability in BIOS where an attacker may cause an Improper Input Validation locally. Successful exploitation of this vulnerability can potentially impact of integrity. | ||||
| CVE-2025-31650 | 2 Apache, Redhat | 2 Tomcat, Jboss Enterprise Web Server | 2025-11-03 | 7.5 High |
| Improper Input Validation vulnerability in Apache Tomcat. Incorrect error handling for some invalid HTTP priority headers resulted in incomplete clean-up of the failed request which created a memory leak. A large number of such requests could trigger an OutOfMemoryException resulting in a denial of service. This issue affects Apache Tomcat: from 9.0.76 through 9.0.102, from 10.1.10 through 10.1.39, from 11.0.0-M2 through 11.0.5. The following versions were EOL at the time the CVE was created but are known to be affected: 8.5.90 though 8.5.100. Users are recommended to upgrade to version 9.0.104, 10.1.40 or 11.0.6 which fix the issue. | ||||
| CVE-2025-31281 | 1 Apple | 7 Ios, Ipados, Iphone Os and 4 more | 2025-11-03 | 9.1 Critical |
| An input validation issue was addressed with improved memory handling. This issue is fixed in visionOS 2.6, tvOS 18.6, macOS Sequoia 15.6, iOS 18.6 and iPadOS 18.6. Processing a maliciously crafted file may lead to unexpected app termination. | ||||
| CVE-2025-31259 | 1 Apple | 1 Macos | 2025-11-03 | 7.8 High |
| The issue was addressed with improved input sanitization. This issue is fixed in macOS Sequoia 15.5. An app may be able to gain elevated privileges. | ||||
| CVE-2025-31240 | 1 Apple | 1 Macos | 2025-11-03 | 7.5 High |
| This issue was addressed with improved checks. This issue is fixed in macOS Ventura 13.7.6, macOS Sequoia 15.5, macOS Sonoma 14.7.6. Mounting a maliciously crafted AFP network share may lead to system termination. | ||||
| CVE-2025-31233 | 1 Apple | 6 Ipados, Iphone Os, Macos and 3 more | 2025-11-03 | 6.3 Medium |
| The issue was addressed with improved input sanitization. This issue is fixed in watchOS 11.5, macOS Sonoma 14.7.6, tvOS 18.5, iPadOS 17.7.7, iOS 18.5 and iPadOS 18.5, macOS Sequoia 15.5, visionOS 2.5, macOS Ventura 13.7.6. Processing a maliciously crafted video file may lead to unexpected app termination or corrupt process memory. | ||||
| CVE-2025-31217 | 1 Apple | 7 Ipados, Iphone Os, Macos and 4 more | 2025-11-03 | 6.5 Medium |
| The issue was addressed with improved input validation. This issue is fixed in watchOS 11.5, tvOS 18.5, iPadOS 17.7.7, iOS 18.5 and iPadOS 18.5, macOS Sequoia 15.5, visionOS 2.5, Safari 18.5. Processing maliciously crafted web content may lead to an unexpected Safari crash. | ||||
| CVE-2025-31215 | 2 Apple, Redhat | 12 Ipados, Iphone Os, Macos and 9 more | 2025-11-03 | 6.5 Medium |
| The issue was addressed with improved checks. This issue is fixed in watchOS 11.5, tvOS 18.5, iPadOS 17.7.7, iOS 18.5 and iPadOS 18.5, macOS Sequoia 15.5, visionOS 2.5, Safari 18.5. Processing maliciously crafted web content may lead to an unexpected process crash. | ||||
| CVE-2025-31208 | 1 Apple | 6 Ipados, Iphone Os, Macos and 3 more | 2025-11-03 | 7.5 High |
| The issue was addressed with improved checks. This issue is fixed in watchOS 11.5, macOS Sonoma 14.7.6, tvOS 18.5, iPadOS 17.7.7, iOS 18.5 and iPadOS 18.5, macOS Sequoia 15.5, visionOS 2.5, macOS Ventura 13.7.6. Parsing a file may lead to an unexpected app termination. | ||||
| CVE-2025-30442 | 1 Apple | 1 Macos | 2025-11-03 | 7.8 High |
| The issue was addressed with improved input sanitization. This issue is fixed in macOS Sequoia 15.4, macOS Ventura 13.7.6, macOS Sonoma 14.7.6. An app may be able to gain elevated privileges. | ||||
| CVE-2025-24274 | 1 Apple | 1 Macos | 2025-11-03 | 7.8 High |
| An input validation issue was addressed by removing the vulnerable code. This issue is fixed in macOS Ventura 13.7.6, macOS Sequoia 15.5, macOS Sonoma 14.7.6. A malicious app may be able to gain root privileges. | ||||
| CVE-2025-22021 | 1 Linux | 1 Linux Kernel | 2025-11-03 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: netfilter: socket: Lookup orig tuple for IPv6 SNAT nf_sk_lookup_slow_v4 does the conntrack lookup for IPv4 packets to restore the original 5-tuple in case of SNAT, to be able to find the right socket (if any). Then socket_match() can correctly check whether the socket was transparent. However, the IPv6 counterpart (nf_sk_lookup_slow_v6) lacks this conntrack lookup, making xt_socket fail to match on the socket when the packet was SNATed. Add the same logic to nf_sk_lookup_slow_v6. IPv6 SNAT is used in Kubernetes clusters for pod-to-world packets, as pods' addresses are in the fd00::/8 ULA subnet and need to be replaced with the node's external address. Cilium leverages Envoy to enforce L7 policies, and Envoy uses transparent sockets. Cilium inserts an iptables prerouting rule that matches on `-m socket --transparent` and redirects the packets to localhost, but it fails to match SNATed IPv6 packets due to that missing conntrack lookup. | ||||
| CVE-2025-21992 | 1 Linux | 1 Linux Kernel | 2025-11-03 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: HID: ignore non-functional sensor in HP 5MP Camera The HP 5MP Camera (USB ID 0408:5473) reports a HID sensor interface that is not actually implemented. Attempting to access this non-functional sensor via iio_info causes system hangs as runtime PM tries to wake up an unresponsive sensor. [453] hid-sensor-hub 0003:0408:5473.0003: Report latency attributes: ffffffff:ffffffff [453] hid-sensor-hub 0003:0408:5473.0003: common attributes: 5:1, 2:1, 3:1 ffffffff:ffffffff Add this device to the HID ignore list since the sensor interface is non-functional by design and should not be exposed to userspace. | ||||
| CVE-2025-21916 | 1 Linux | 1 Linux Kernel | 2025-11-03 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: usb: atm: cxacru: fix a flaw in existing endpoint checks Syzbot once again identified a flaw in usb endpoint checking, see [1]. This time the issue stems from a commit authored by me (2eabb655a968 ("usb: atm: cxacru: fix endpoint checking in cxacru_bind()")). While using usb_find_common_endpoints() may usually be enough to discard devices with wrong endpoints, in this case one needs more than just finding and identifying the sufficient number of endpoints of correct types - one needs to check the endpoint's address as well. Since cxacru_bind() fills URBs with CXACRU_EP_CMD address in mind, switch the endpoint verification approach to usb_check_XXX_endpoints() instead to fix incomplete ep testing. [1] Syzbot report: usb 5-1: BOGUS urb xfer, pipe 3 != type 1 WARNING: CPU: 0 PID: 1378 at drivers/usb/core/urb.c:504 usb_submit_urb+0xc4e/0x18c0 drivers/usb/core/urb.c:503 ... RIP: 0010:usb_submit_urb+0xc4e/0x18c0 drivers/usb/core/urb.c:503 ... Call Trace: <TASK> cxacru_cm+0x3c8/0xe50 drivers/usb/atm/cxacru.c:649 cxacru_card_status drivers/usb/atm/cxacru.c:760 [inline] cxacru_bind+0xcf9/0x1150 drivers/usb/atm/cxacru.c:1223 usbatm_usb_probe+0x314/0x1d30 drivers/usb/atm/usbatm.c:1058 cxacru_usb_probe+0x184/0x220 drivers/usb/atm/cxacru.c:1377 usb_probe_interface+0x641/0xbb0 drivers/usb/core/driver.c:396 really_probe+0x2b9/0xad0 drivers/base/dd.c:658 __driver_probe_device+0x1a2/0x390 drivers/base/dd.c:800 driver_probe_device+0x50/0x430 drivers/base/dd.c:830 ... | ||||
| CVE-2025-21913 | 1 Linux | 1 Linux Kernel | 2025-11-03 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: x86/amd_nb: Use rdmsr_safe() in amd_get_mmconfig_range() Xen doesn't offer MSR_FAM10H_MMIO_CONF_BASE to all guests. This results in the following warning: unchecked MSR access error: RDMSR from 0xc0010058 at rIP: 0xffffffff8101d19f (xen_do_read_msr+0x7f/0xa0) Call Trace: xen_read_msr+0x1e/0x30 amd_get_mmconfig_range+0x2b/0x80 quirk_amd_mmconfig_area+0x28/0x100 pnp_fixup_device+0x39/0x50 __pnp_add_device+0xf/0x150 pnp_add_device+0x3d/0x100 pnpacpi_add_device_handler+0x1f9/0x280 acpi_ns_get_device_callback+0x104/0x1c0 acpi_ns_walk_namespace+0x1d0/0x260 acpi_get_devices+0x8a/0xb0 pnpacpi_init+0x50/0x80 do_one_initcall+0x46/0x2e0 kernel_init_freeable+0x1da/0x2f0 kernel_init+0x16/0x1b0 ret_from_fork+0x30/0x50 ret_from_fork_asm+0x1b/0x30 based on quirks for a "PNP0c01" device. Treating MMCFG as disabled is the right course of action, so no change is needed there. This was most likely exposed by fixing the Xen MSR accessors to not be silently-safe. | ||||