Total
2246 CVE
| CVE | Vendors | Products | Updated | CVSS v3.1 |
|---|---|---|---|---|
| CVE-2024-7885 | 1 Redhat | 21 Apache Camel Hawtio, Apache Camel Spring Boot, Build Keycloak and 18 more | 2026-01-19 | 7.5 High |
| A vulnerability was found in Undertow where the ProxyProtocolReadListener reuses the same StringBuilder instance across multiple requests. This issue occurs when the parseProxyProtocolV1 method processes multiple requests on the same HTTP connection. As a result, different requests may share the same StringBuilder instance, potentially leading to information leakage between requests or responses. In some cases, a value from a previous request or response may be erroneously reused, which could lead to unintended data exposure. This issue primarily results in errors and connection termination but creates a risk of data leakage in multi-request environments. | ||||
| CVE-2026-20874 | 1 Microsoft | 16 Windows 10 1809, Windows 10 21h2, Windows 10 21h2 and 13 more | 2026-01-16 | 7.8 High |
| Concurrent execution using shared resource with improper synchronization ('race condition') in Windows Management Services allows an authorized attacker to elevate privileges locally. | ||||
| CVE-2026-20873 | 1 Microsoft | 16 Windows 10 1809, Windows 10 21h2, Windows 10 21h2 and 13 more | 2026-01-16 | 7.8 High |
| Concurrent execution using shared resource with improper synchronization ('race condition') in Windows Management Services allows an authorized attacker to elevate privileges locally. | ||||
| CVE-2026-20867 | 1 Microsoft | 16 Windows 10 1809, Windows 10 21h2, Windows 10 21h2 and 13 more | 2026-01-16 | 7.8 High |
| Concurrent execution using shared resource with improper synchronization ('race condition') in Windows Management Services allows an authorized attacker to elevate privileges locally. | ||||
| CVE-2026-20866 | 1 Microsoft | 16 Windows 10 1809, Windows 10 21h2, Windows 10 21h2 and 13 more | 2026-01-16 | 7.8 High |
| Concurrent execution using shared resource with improper synchronization ('race condition') in Windows Management Services allows an authorized attacker to elevate privileges locally. | ||||
| CVE-2026-20861 | 1 Microsoft | 16 Windows 10 1809, Windows 10 21h2, Windows 10 21h2 and 13 more | 2026-01-16 | 7.8 High |
| Concurrent execution using shared resource with improper synchronization ('race condition') in Windows Management Services allows an authorized attacker to elevate privileges locally. | ||||
| CVE-2026-20934 | 1 Microsoft | 20 Windows 10 1607, Windows 10 1809, Windows 10 21h2 and 17 more | 2026-01-16 | 7.5 High |
| Concurrent execution using shared resource with improper synchronization ('race condition') in Windows SMB Server allows an authorized attacker to elevate privileges over a network. | ||||
| CVE-2026-20927 | 1 Microsoft | 23 Windows 10 1607, Windows 10 1809, Windows 10 21h2 and 20 more | 2026-01-16 | 5.3 Medium |
| Concurrent execution using shared resource with improper synchronization ('race condition') in Windows SMB Server allows an authorized attacker to deny service over a network. | ||||
| CVE-2026-20926 | 1 Microsoft | 20 Windows 10 1607, Windows 10 1809, Windows 10 21h2 and 17 more | 2026-01-16 | 7.5 High |
| Concurrent execution using shared resource with improper synchronization ('race condition') in Windows SMB Server allows an authorized attacker to elevate privileges over a network. | ||||
| CVE-2026-20924 | 1 Microsoft | 16 Windows 10 1809, Windows 10 21h2, Windows 10 21h2 and 13 more | 2026-01-16 | 7.8 High |
| Use after free in Windows Management Services allows an authorized attacker to elevate privileges locally. | ||||
| CVE-2026-20921 | 1 Microsoft | 23 Windows 10 1607, Windows 10 1809, Windows 10 21h2 and 20 more | 2026-01-16 | 7.5 High |
| Concurrent execution using shared resource with improper synchronization ('race condition') in Windows SMB Server allows an authorized attacker to elevate privileges over a network. | ||||
| CVE-2026-20919 | 1 Microsoft | 20 Windows 10 1607, Windows 10 1809, Windows 10 21h2 and 17 more | 2026-01-16 | 7.5 High |
| Concurrent execution using shared resource with improper synchronization ('race condition') in Windows SMB Server allows an authorized attacker to elevate privileges over a network. | ||||
| CVE-2026-20918 | 1 Microsoft | 16 Windows 10 1809, Windows 10 21h2, Windows 10 21h2 and 13 more | 2026-01-16 | 7.8 High |
| Concurrent execution using shared resource with improper synchronization ('race condition') in Windows Management Services allows an authorized attacker to elevate privileges locally. | ||||
| CVE-2026-20877 | 1 Microsoft | 16 Windows 10 1809, Windows 10 21h2, Windows 10 21h2 and 13 more | 2026-01-16 | 7.8 High |
| Use after free in Windows Management Services allows an authorized attacker to elevate privileges locally. | ||||
| CVE-2026-20869 | 1 Microsoft | 23 Windows 10 1607, Windows 10 1809, Windows 10 21h2 and 20 more | 2026-01-16 | 7 High |
| Concurrent execution using shared resource with improper synchronization ('race condition') in Windows Local Session Manager (LSM) allows an authorized attacker to elevate privileges locally. | ||||
| CVE-2026-20858 | 1 Microsoft | 16 Windows 10 1809, Windows 10 21h2, Windows 10 21h2 and 13 more | 2026-01-16 | 7.8 High |
| Use after free in Windows Management Services allows an authorized attacker to elevate privileges locally. | ||||
| CVE-2026-20808 | 1 Microsoft | 7 Windows 11 24h2, Windows 11 24h2, Windows 11 25h2 and 4 more | 2026-01-16 | 7 High |
| Concurrent execution using shared resource with improper synchronization ('race condition') in Printer Association Object allows an authorized attacker to elevate privileges locally. | ||||
| CVE-2023-53452 | 1 Linux | 1 Linux Kernel | 2026-01-16 | 4.7 Medium |
| In the Linux kernel, the following vulnerability has been resolved: wifi: rtw89: fix potential race condition between napi_init and napi_enable A race condition can happen if netdev is registered, but NAPI isn't initialized yet, and meanwhile user space starts the netdev that will enable NAPI. Then, it hits BUG_ON(): kernel BUG at net/core/dev.c:6423! invalid opcode: 0000 [#1] PREEMPT SMP NOPTI CPU: 0 PID: 417 Comm: iwd Not tainted 6.2.7-slab-dirty #3 eb0f5a8a9d91 Hardware name: LENOVO 21DL/LNVNB161216, BIOS JPCN20WW(V1.06) 09/20/2022 RIP: 0010:napi_enable+0x3f/0x50 Code: 48 89 c2 48 83 e2 f6 f6 81 89 08 00 00 02 74 0d 48 83 ... RSP: 0018:ffffada1414f3548 EFLAGS: 00010246 RAX: 0000000000000000 RBX: ffffa01425802080 RCX: 0000000000000000 RDX: 00000000000002ff RSI: ffffada14e50c614 RDI: ffffa01425808dc0 RBP: 0000000000000000 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000001 R11: 0000000000000100 R12: ffffa01425808f58 R13: 0000000000000000 R14: ffffa01423498940 R15: 0000000000000001 FS: 00007f5577c0a740(0000) GS:ffffa0169fc00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f5577a19972 CR3: 0000000125a7a000 CR4: 0000000000750ef0 PKRU: 55555554 Call Trace: <TASK> rtw89_pci_ops_start+0x1c/0x70 [rtw89_pci 6cbc75429515c181cbc386478d5cfb32ffc5a0f8] rtw89_core_start+0xbe/0x160 [rtw89_core fe07ecb874820b6d778370d4acb6ef8a37847f22] rtw89_ops_start+0x26/0x40 [rtw89_core fe07ecb874820b6d778370d4acb6ef8a37847f22] drv_start+0x42/0x100 [mac80211 c07fa22af8c3cf3f7d7ab3884ca990784d72e2d2] ieee80211_do_open+0x311/0x7d0 [mac80211 c07fa22af8c3cf3f7d7ab3884ca990784d72e2d2] ieee80211_open+0x6a/0x90 [mac80211 c07fa22af8c3cf3f7d7ab3884ca990784d72e2d2] __dev_open+0xe0/0x180 __dev_change_flags+0x1da/0x250 dev_change_flags+0x26/0x70 do_setlink+0x37c/0x12c0 ? ep_poll_callback+0x246/0x290 ? __nla_validate_parse+0x61/0xd00 ? __wake_up_common_lock+0x8f/0xd0 To fix this, follow Jonas' suggestion to switch the order of these functions and move register netdev to be the last step of PCI probe. Also, correct the error handling of rtw89_core_register_hw(). | ||||
| CVE-2023-53490 | 1 Linux | 1 Linux Kernel | 2026-01-16 | 4.7 Medium |
| In the Linux kernel, the following vulnerability has been resolved: mptcp: fix disconnect vs accept race Despite commit 0ad529d9fd2b ("mptcp: fix possible divide by zero in recvmsg()"), the mptcp protocol is still prone to a race between disconnect() (or shutdown) and accept. The root cause is that the mentioned commit checks the msk-level flag, but mptcp_stream_accept() does acquire the msk-level lock, as it can rely directly on the first subflow lock. As reported by Christoph than can lead to a race where an msk socket is accepted after that mptcp_subflow_queue_clean() releases the listener socket lock and just before it takes destructive actions leading to the following splat: BUG: kernel NULL pointer dereference, address: 0000000000000012 PGD 5a4ca067 P4D 5a4ca067 PUD 37d4c067 PMD 0 Oops: 0000 [#1] PREEMPT SMP CPU: 2 PID: 10955 Comm: syz-executor.5 Not tainted 6.5.0-rc1-gdc7b257ee5dd #37 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.11.0-2.el7 04/01/2014 RIP: 0010:mptcp_stream_accept+0x1ee/0x2f0 include/net/inet_sock.h:330 Code: 0a 09 00 48 8b 1b 4c 39 e3 74 07 e8 bc 7c 7f fe eb a1 e8 b5 7c 7f fe 4c 8b 6c 24 08 eb 05 e8 a9 7c 7f fe 49 8b 85 d8 09 00 00 <0f> b6 40 12 88 44 24 07 0f b6 6c 24 07 bf 07 00 00 00 89 ee e8 89 RSP: 0018:ffffc90000d07dc0 EFLAGS: 00010293 RAX: 0000000000000000 RBX: ffff888037e8d020 RCX: ffff88803b093300 RDX: 0000000000000000 RSI: ffffffff833822c5 RDI: ffffffff8333896a RBP: 0000607f82031520 R08: ffff88803b093300 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000003e83 R12: ffff888037e8d020 R13: ffff888037e8c680 R14: ffff888009af7900 R15: ffff888009af6880 FS: 00007fc26d708640(0000) GS:ffff88807dd00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000012 CR3: 0000000066bc5001 CR4: 0000000000370ee0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: <TASK> do_accept+0x1ae/0x260 net/socket.c:1872 __sys_accept4+0x9b/0x110 net/socket.c:1913 __do_sys_accept4 net/socket.c:1954 [inline] __se_sys_accept4 net/socket.c:1951 [inline] __x64_sys_accept4+0x20/0x30 net/socket.c:1951 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x47/0xa0 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x6e/0xd8 Address the issue by temporary removing the pending request socket from the accept queue, so that racing accept() can't touch them. After depleting the msk - the ssk still exists, as plain TCP sockets, re-insert them into the accept queue, so that later inet_csk_listen_stop() will complete the tcp socket disposal. | ||||
| CVE-2025-39825 | 2 Debian, Linux | 2 Debian Linux, Linux Kernel | 2026-01-16 | 4.7 Medium |
| In the Linux kernel, the following vulnerability has been resolved: smb: client: fix race with concurrent opens in rename(2) Besides sending the rename request to the server, the rename process also involves closing any deferred close, waiting for outstanding I/O to complete as well as marking all existing open handles as deleted to prevent them from deferring closes, which increases the race window for potential concurrent opens on the target file. Fix this by unhashing the dentry in advance to prevent any concurrent opens on the target. | ||||