Total
34008 CVE
| CVE | Vendors | Products | Updated | CVSS v3.1 |
|---|---|---|---|---|
| CVE-2025-59494 | 1 Microsoft | 2 Azure, Azure Monitor Agent | 2025-12-11 | 7.8 High |
| Improper access control in Azure Monitor Agent allows an authorized attacker to elevate privileges locally. | ||||
| CVE-2025-59294 | 1 Microsoft | 25 Windows, Windows 10, Windows 10 1507 and 22 more | 2025-12-11 | 2.1 Low |
| Exposure of sensitive information to an unauthorized actor in Windows Taskbar Live allows an unauthorized attacker to disclose information with a physical attack. | ||||
| CVE-2025-59284 | 1 Microsoft | 12 Windows, Windows 11, Windows 11 22h2 and 9 more | 2025-12-11 | 3.3 Low |
| Exposure of sensitive information to an unauthorized actor in Windows NTLM allows an unauthorized attacker to perform spoofing locally. | ||||
| CVE-2025-59250 | 1 Microsoft | 10 Jdbc Driver For Sql Server, Jdbc Driver For Sql Server 10.2, Jdbc Driver For Sql Server 11.2 and 7 more | 2025-12-11 | 8.1 High |
| Improper input validation in JDBC Driver for SQL Server allows an unauthorized attacker to perform spoofing over a network. | ||||
| CVE-2025-59249 | 1 Microsoft | 6 Exchange, Exchange Server, Exchange Server 2016 and 3 more | 2025-12-11 | 8.8 High |
| Weak authentication in Microsoft Exchange Server allows an authorized attacker to elevate privileges over a network. | ||||
| CVE-2025-59228 | 1 Microsoft | 3 Sharepoint Server, Sharepoint Server 2016, Sharepoint Server 2019 | 2025-12-11 | 8.8 High |
| Improper input validation in Microsoft Office SharePoint allows an authorized attacker to execute code over a network. | ||||
| CVE-2025-59199 | 1 Microsoft | 18 Windows 10 1809, Windows 10 21h2, Windows 10 21h2 and 15 more | 2025-12-11 | 7.8 High |
| Improper access control in Software Protection Platform (SPP) allows an authorized attacker to elevate privileges locally. | ||||
| CVE-2025-59186 | 1 Microsoft | 6 Windows Server 2016, Windows Server 2019, Windows Server 2022 and 3 more | 2025-12-11 | 5.5 Medium |
| Exposure of sensitive information to an unauthorized actor in Windows Kernel allows an authorized attacker to disclose information locally. | ||||
| CVE-2025-58716 | 1 Microsoft | 21 Windows 10 1507, Windows 10 1607, Windows 10 1809 and 18 more | 2025-12-11 | 8.8 High |
| Improper input validation in Microsoft Windows Speech allows an authorized attacker to elevate privileges locally. | ||||
| CVE-2025-55336 | 1 Microsoft | 22 Windows, Windows 10, Windows 10 1809 and 19 more | 2025-12-11 | 5.5 Medium |
| Exposure of sensitive information to an unauthorized actor in Windows Cloud Files Mini Filter Driver allows an authorized attacker to disclose information locally. | ||||
| CVE-2025-53782 | 1 Microsoft | 4 Exchange Server, Exchange Server 2016, Exchange Server 2019 and 1 more | 2025-12-11 | 8.4 High |
| Incorrect implementation of authentication algorithm in Microsoft Exchange Server allows an unauthorized attacker to elevate privileges locally. | ||||
| CVE-2025-21073 | 1 Samsung | 2 Android, Mobile Devices | 2025-12-11 | 6.8 Medium |
| Insecure default configuration in USB connection mode prior to SMR Nov-2025 Release 1 allows privileged physical attackers to access user data. User interaction is required for triggering this vulnerability. | ||||
| CVE-2025-66490 | 1 Traefik | 1 Traefik | 2025-12-11 | 6.5 Medium |
| Traefik is an HTTP reverse proxy and load balancer. For versions prior to 2.11.32 and 2.11.31 through 3.6.2, requests using PathPrefix, Path or PathRegex matchers can bypass path normalization. When Traefik uses path-based routing, requests containing URL-encoded restricted characters (/, \, Null, ;, ?, #) can bypass the middleware chain and reach unintended backends. For example, a request to http://mydomain.example.com/admin%2F could reach service-a without triggering my-security-middleware, bypassing security controls for the /admin/ path. This issue is fixed in versions 2.11.32 and 3.6.3. | ||||
| CVE-2025-39926 | 1 Linux | 1 Linux Kernel | 2025-12-11 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: genetlink: fix genl_bind() invoking bind() after -EPERM Per family bind/unbind callbacks were introduced to allow families to track multicast group consumer presence, e.g. to start or stop producing events depending on listeners. However, in genl_bind() the bind() callback was invoked even if capability checks failed and ret was set to -EPERM. This means that callbacks could run on behalf of unauthorized callers while the syscall still returned failure to user space. Fix this by only invoking bind() after "if (ret) break;" check i.e. after permission checks have succeeded. | ||||
| CVE-2025-39925 | 1 Linux | 1 Linux Kernel | 2025-12-11 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: can: j1939: implement NETDEV_UNREGISTER notification handler syzbot is reporting unregister_netdevice: waiting for vcan0 to become free. Usage count = 2 problem, for j1939 protocol did not have NETDEV_UNREGISTER notification handler for undoing changes made by j1939_sk_bind(). Commit 25fe97cb7620 ("can: j1939: move j1939_priv_put() into sk_destruct callback") expects that a call to j1939_priv_put() can be unconditionally delayed until j1939_sk_sock_destruct() is called. But we need to call j1939_priv_put() against an extra ref held by j1939_sk_bind() call (as a part of undoing changes made by j1939_sk_bind()) as soon as NETDEV_UNREGISTER notification fires (i.e. before j1939_sk_sock_destruct() is called via j1939_sk_release()). Otherwise, the extra ref on "struct j1939_priv" held by j1939_sk_bind() call prevents "struct net_device" from dropping the usage count to 1; making it impossible for unregister_netdevice() to continue. [mkl: remove space in front of label] | ||||
| CVE-2025-39924 | 1 Linux | 1 Linux Kernel | 2025-12-11 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: erofs: fix invalid algorithm for encoded extents The current algorithm sanity checks do not properly apply to new encoded extents. Unify the algorithm check with Z_EROFS_COMPRESSION(_RUNTIME)_MAX and ensure consistency with sbi->available_compr_algs. | ||||
| CVE-2025-39921 | 1 Linux | 1 Linux Kernel | 2025-12-11 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: spi: microchip-core-qspi: stop checking viability of op->max_freq in supports_op callback In commit 13529647743d9 ("spi: microchip-core-qspi: Support per spi-mem operation frequency switches") the logic for checking the viability of op->max_freq in mchp_coreqspi_setup_clock() was copied into mchp_coreqspi_supports_op(). Unfortunately, op->max_freq is not valid when this function is called during probe but is instead zero. Accordingly, baud_rate_val is calculated to be INT_MAX due to division by zero, causing probe of the attached memory device to fail. Seemingly spi-microchip-core-qspi was the only driver that had such a modification made to its supports_op callback when the per_op_freq capability was added, so just remove it to restore prior functionality. | ||||
| CVE-2025-39919 | 1 Linux | 1 Linux Kernel | 2025-12-11 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: wifi: mt76: mt7996: add missing check for rx wcid entries Non-station wcid entries must not be passed to the rx functions. In case of the global wcid entry, it could even lead to corruption in the wcid array due to pointer being casted to struct mt7996_sta_link using container_of. | ||||
| CVE-2023-53383 | 1 Linux | 1 Linux Kernel | 2025-12-11 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: irqchip/gicv3: Workaround for NVIDIA erratum T241-FABRIC-4 The T241 platform suffers from the T241-FABRIC-4 erratum which causes unexpected behavior in the GIC when multiple transactions are received simultaneously from different sources. This hardware issue impacts NVIDIA server platforms that use more than two T241 chips interconnected. Each chip has support for 320 {E}SPIs. This issue occurs when multiple packets from different GICs are incorrectly interleaved at the target chip. The erratum text below specifies exactly what can cause multiple transfer packets susceptible to interleaving and GIC state corruption. GIC state corruption can lead to a range of problems, including kernel panics, and unexpected behavior. >From the erratum text: "In some cases, inter-socket AXI4 Stream packets with multiple transfers, may be interleaved by the fabric when presented to ARM Generic Interrupt Controller. GIC expects all transfers of a packet to be delivered without any interleaving. The following GICv3 commands may result in multiple transfer packets over inter-socket AXI4 Stream interface: - Register reads from GICD_I* and GICD_N* - Register writes to 64-bit GICD registers other than GICD_IROUTERn* - ITS command MOVALL Multiple commands in GICv4+ utilize multiple transfer packets, including VMOVP, VMOVI, VMAPP, and 64-bit register accesses." This issue impacts system configurations with more than 2 sockets, that require multi-transfer packets to be sent over inter-socket AXI4 Stream interface between GIC instances on different sockets. GICv4 cannot be supported. GICv3 SW model can only be supported with the workaround. Single and Dual socket configurations are not impacted by this issue and support GICv3 and GICv4." Writing to the chip alias region of the GICD_In{E} registers except GICD_ICENABLERn has an equivalent effect as writing to the global distributor. The SPI interrupt deactivate path is not impacted by the erratum. To fix this problem, implement a workaround that ensures read accesses to the GICD_In{E} registers are directed to the chip that owns the SPI, and disable GICv4.x features. To simplify code changes, the gic_configure_irq() function uses the same alias region for both read and write operations to GICD_ICFGR. | ||||
| CVE-2023-53387 | 1 Linux | 1 Linux Kernel | 2025-12-11 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: scsi: ufs: core: Fix device management cmd timeout flow In the UFS error handling flow, the host will send a device management cmd (NOP OUT) to the device for link recovery. If this cmd times out and clearing the doorbell fails, ufshcd_wait_for_dev_cmd() will do nothing and return. hba->dev_cmd.complete struct is not set to NULL. When this happens, if cmd has been completed by device, then we will call complete() in __ufshcd_transfer_req_compl(). Because the complete struct is allocated on the stack, the following crash will occur: ipanic_die+0x24/0x38 [mrdump] die+0x344/0x748 arm64_notify_die+0x44/0x104 do_debug_exception+0x104/0x1e0 el1_dbg+0x38/0x54 el1_sync_handler+0x40/0x88 el1_sync+0x8c/0x140 queued_spin_lock_slowpath+0x2e4/0x3c0 __ufshcd_transfer_req_compl+0x3b0/0x1164 ufshcd_trc_handler+0x15c/0x308 ufshcd_host_reset_and_restore+0x54/0x260 ufshcd_reset_and_restore+0x28c/0x57c ufshcd_err_handler+0xeb8/0x1b6c process_one_work+0x288/0x964 worker_thread+0x4bc/0xc7c kthread+0x15c/0x264 ret_from_fork+0x10/0x30 | ||||