Total
2854 CVE
| CVE | Vendors | Products | Updated | CVSS v3.1 |
|---|---|---|---|---|
| CVE-2026-87641 | 1 Google | 1 Chrome | 2026-09-10 | 4.2 Medium |
| Race condition in Browser in Google Chrome prior to 153.0.8010.36 allowed a remote attacker to bypass system access restrictions via a crafted HTML page. (Chromium security severity: Medium) | ||||
| CVE-2026-87615 | 1 Google | 1 Chrome | 2026-09-10 | 5.4 Medium |
| Race condition in Payments in Google Chrome prior to 153.0.8010.36 allowed a remote attacker leveraging social engineering to spoof UI elements via a crafted HTML page. (Chromium security severity: Medium) | ||||
| CVE-2026-80914 | 1 Linux | 1 Linux Kernel | 2026-09-10 | 8.8 High |
| In the Linux kernel, the following vulnerability has been resolved: Bluetooth: ISO: fix use-after-free of listener socket in iso_conn_ready iso_conn_ready() looks up the BIS listener socket with iso_get_sock(), which takes a reference, and then, without re-checking its state, creates a child socket from it: parent = iso_get_sock(hdev, ...); if (!parent) return; lock_sock(parent); sk = iso_sock_alloc(sock_net(parent), NULL, BTPROTO_ISO, ...); ... iso_chan_add(conn, sk, parent); ... release_sock(parent); sock_put(parent); If the listener socket is closed concurrently, between iso_get_sock() and lock_sock(), the reference taken by iso_get_sock() may be the last one: the close path drops the link-list reference, and once iso_conn_ready() drops its own reference at the end of the function the socket is freed. The child socket, however, is already linked to the freed parent, and a later disconnect of the child runs iso_chan_del() -> bt_accept_unlink(), which dereferences the dangling parent pointer into the freed accept queue (a use-after-free). The same dangling pointer is also dereferenced through parent->***() in iso_chan_del(). Fix it the same way the connected (non-BIS) path was fixed in commit 0d255e63fcf3 ("Bluetooth: ISO: hold sk properly in iso_conn_ready"): after taking the socket lock, re-check that the parent is still a listening, alive socket, and bail out otherwise. | ||||
| CVE-2026-69448 | 1 Microsoft | 8 Windows 10 21h2, Windows 10 22h2, Windows 11 23h2 and 5 more | 2026-09-10 | 7 High |
| Concurrent execution using shared resource with improper synchronization ('race condition') in Windows Bluetooth Service allows an authorized attacker to elevate privileges locally. | ||||
| CVE-2026-69385 | 1 Microsoft | 14 Windows 10 1607, Windows 10 1809, Windows 10 21h2 and 11 more | 2026-09-09 | 7 High |
| Concurrent execution using shared resource with improper synchronization ('race condition') in Windows TCP/IP allows an authorized attacker to elevate privileges locally. | ||||
| CVE-2026-69364 | 1 Microsoft | 14 Windows 10 1607, Windows 10 1809, Windows 10 21h2 and 11 more | 2026-09-09 | 7.1 High |
| Concurrent execution using shared resource with improper synchronization ('race condition') in Windows Print Spooler Components allows an authorized attacker to elevate privileges over a network. | ||||
| CVE-2026-50349 | 1 Microsoft | 26 Windows 10 1607, Windows 10 1809, Windows 10 21h2 and 23 more | 2026-09-09 | 7 High |
| Concurrent execution using shared resource with improper synchronization ('race condition') in Windows Ancillary Function Driver for WinSock allows an authorized attacker to elevate privileges locally. | ||||
| CVE-2026-70582 | 1 Microsoft | 14 Windows 10 1607, Windows 10 1809, Windows 10 21h2 and 11 more | 2026-09-09 | 6.4 Medium |
| Concurrent execution using shared resource with improper synchronization ('race condition') in Windows Management Instrumentation allows an authorized attacker to elevate privileges locally. | ||||
| CVE-2026-69782 | 1 Microsoft | 8 Windows 10 1607, Windows 10 1809, Windows Server 2012 and 5 more | 2026-09-09 | 8.1 High |
| Concurrent execution using shared resource with improper synchronization ('race condition') in DNS Server allows an unauthorized attacker to execute code over a network. | ||||
| CVE-2026-58848 | 2026-09-09 | 7 High | ||
| In multiple functions of alloc.c, there is a possible unauthorized read/write access due to a race condition. This could lead to local escalation of privilege with no additional execution privileges needed. User interaction is not needed for exploitation. | ||||
| CVE-2026-68840 | 1 Microsoft | 13 Windows 10 1607, Windows 10 1809, Windows 10 21h2 and 10 more | 2026-09-09 | 7 High |
| Concurrent execution using shared resource with improper synchronization ('race condition') in Windows USB Driver allows an authorized attacker to elevate privileges locally. | ||||
| CVE-2026-87467 | 2 Google, Microsoft | 2 Chrome, Windows | 2026-09-09 | 8.1 High |
| Race condition in Updater in Google Chrome on on Windows prior to 153.0.8010.36 allowed a local attacker to potentially execute arbitrary code outside the sandbox via a local program. (Chromium security severity: High) | ||||
| CVE-2026-87601 | 1 Google | 1 Chrome | 2026-09-09 | 7.5 High |
| Race condition in V8 in Google Chrome prior to 153.0.8010.36 allowed a remote attacker to execute arbitrary code inside the sandbox via a crafted HTML page. (Chromium security severity: Low) | ||||
| CVE-2026-80920 | 1 Linux | 1 Linux Kernel | 2026-09-09 | N/A |
| In the Linux kernel, the following vulnerability has been resolved: io_uring: defer eventfd signaling when queued from a wakeup handler io_req_local_work_add() signals the CQ ring eventfd inline when it is the one to push the first entry onto ->work_list. For DEFER_TASKRUN rings that add is frequently done from a waitqueue wakeup handler, where an arbitrary waitqueue lock is held. eventfd_signal_mask() only refuses to recurse when current->in_eventfd is set, but that bit is set by eventfd_signal_mask() itself. If the wake chain starts somewhere else, signal goes out inline and can feed back into epoll. Add IOU_F_TWQ_IN_WAKE, set it on the task_work add done from the three waitqueue callbacks, and use it to force io_eventfd_signal() down the existing call_rcu_hurry() deferral instead of signaling inline. | ||||
| CVE-2026-69581 | 1 Microsoft | 13 Windows 10 1607, Windows 10 1809, Windows 10 21h2 and 10 more | 2026-09-09 | 7 High |
| Use after free in Windows Device Association Service allows an authorized attacker to elevate privileges locally. | ||||
| CVE-2026-80916 | 1 Linux | 1 Linux Kernel | 2026-09-09 | N/A |
| In the Linux kernel, the following vulnerability has been resolved: kcov: fix data corruption and race conditions on PREEMPT_RT syzbot is reporting KCOV state corruption on PREEMPT_RT kernels, for the temporary storage used for saving/restoring remote KCOV state is currently allocated as the per-CPU area. On PREEMPT_RT kernels, softirq handlers run as preemptible task threads (e.g., ksoftirqd). If a softirq context preempts a task running a remote KCOV session, it safely saves the task's state into the per-CPU area. However, if that softirq thread is subsequently preempted by a higher- priority softirq thread on the same CPU, the second softirq will overwrite the same per-CPU area, permanently destroying the original task's KCOV state. Fix this data corruption by moving the temporary storage from the per-CPU area to the per-thread area. Since each softirq thread now owns its own task context, nested softirq preemption no longer causes data overwrites. Note that while the temporary storage is now on a per-thread basis, the per-CPU kcov_percpu_data.lock must be retained, for we need to ensure that kcov_remote_start() and kcov_remote_stop() operate atomically without racing against asynchronous interrupts that manipulate the current task's KCOV state. It is likely that GFP_KERNEL allocation by vmalloc_node() in kcov_init() has already called panic() before returning NULL, for there will be no OOM-killable userspace processes when __init function of built-in module runs. But this patch also fixes crashing the kernel when vmalloc_node() in kcov_init() returned NULL, for kcov_init() left per-CPU irq_area == NULL but kcov_remote_start() depends on per-CPU irq_area != NULL, resulting in (1) doing vmalloc() in kcov_remote_start() despite !in_task() context (2) out-of-array-bounds access if (1) succeeded but kcov->remote_size < CONFIG_KCOV_IRQ_AREA_SIZE (3) always leak memory allocated by (1), eventually killing all OOM-killable userspace processes problems. | ||||
| CVE-2026-73005 | 1 Microsoft | 12 Windows 10 1607, Windows 10 1809, Windows 10 21h2 and 9 more | 2026-09-09 | 7 High |
| Use after free in Windows Authentication Methods allows an authorized attacker to elevate privileges locally. | ||||
| CVE-2026-69792 | 1 Microsoft | 12 Windows 10 1607, Windows 10 1809, Windows 10 21h2 and 9 more | 2026-09-09 | 4.7 Medium |
| Concurrent execution using shared resource with improper synchronization ('race condition') in Windows Win32K allows an authorized attacker to bypass a security feature locally. | ||||
| CVE-2026-69682 | 1 Microsoft | 10 Windows 10 1809, Windows 10 21h2, Windows 10 22h2 and 7 more | 2026-09-09 | 7 High |
| Use after free in Windows Host Guardian Service allows an authorized attacker to elevate privileges locally. | ||||
| CVE-2026-86766 | 1 Snipeitapp | 1 Snipe-it | 2026-09-09 | 6.5 Medium |
| Snipe-IT versions up to and including 8.6.3 contain a race condition (TOCTOU) in the consumable checkout API endpoint (POST /api/v1/consumables/{consumable_id}/checkout). The requested quantity is validated against the number of remaining units before the database transaction begins, and the transaction then creates the checkout records without locking the consumable row or re-checking availability. An authenticated user with permission to check out consumables can submit concurrent checkout requests for the same consumable so that both requests pass the availability check and succeed, over-allocating stock and driving the remaining inventory negative (e.g., a consumable with 1 remaining unit ends at -1 after two concurrent 1-unit checkouts). The issue is fixed in 8.7.0, which re-fetches the parent row under lockForUpdate inside the transaction and re-validates availability. | ||||