CVE Watch358,897 in full archive

Vulnerabilities exploitable today

358,897in current view

Single score combining CVSS, KEV membership and EPSS. Every CVE with its own record — timeline from publication to active exploitation.

In KEV catalog1,665

New KEV · 24H0

Exploit Today ≥ 701,607

Distribution · last window

Critical
2,706
High
11,663
Medium
7,433
Low
683

Filters

Window

Severity

Flags

Vulnerabilities322,681–322,720 · 358,897

CVECVSSEPSSKEVRExploitTitleMod.

——3——CVE-2023-533748.8 HIG

9.7%

——3In the Linux kernel, the following vulnerability has been resolved: Bluetooth: hci_conn: fail SCO/ISO via hci_conn_failed if ACL gone early Not calling hci_(dis)connect_cfm before deleting conn referred to by a socket generally results to use-after-free. When cleaning up SCO connections when the parent ACL is deleted too early, use hci_conn_failed to do the connection cleanup properly. We also need to clean up ISO connections in a similar situation when connecting has started but LE Create CIS is not yet sent, so do it too here.9d CVE-2024-3758—

——3——CVE-2026-504597.0 HIG

9.7%

——3Use after free in Windows Kernel allows an unauthorized attacker to elevate privileges locally.21d CVE-2023-22283—

——3——CVE-2025-220907.3 HIG

9.7%

——3In the Linux kernel, the following vulnerability has been resolved: x86/mm/pat: Fix VM_PAT handling when fork() fails in copy_page_range() If track_pfn_copy() fails, we already added the dst VMA to the maple tree. As fork() fails, we'll cleanup the maple tree, and stumble over the dst VMA for which we neither performed any reservation nor copied any page tables. Consequently untrack_pfn() will see VM_PAT and try obtaining the PAT information from the page table -- which fails because the page table was not copied. The easiest fix would be to simply clear the VM_PAT flag of the dst VMA if track_pfn_copy() fails. However, the whole thing is about "simply" clearing the VM_PAT flag is shaky as well: if we passed track_pfn_copy() and performed a reservation, but copying the page tables fails, we'll simply clear the VM_PAT flag, not properly undoing the reservation ... which is also wrong. So let's fix it properly: set the VM_PAT flag only if the reservation succeeded (leaving it clear initially), and undo the reservation if anything goes wrong while copying the page tables: clearing the VM_PAT flag after undoing the reservation. Note that any copied page table entries will get zapped when the VMA will get removed later, after copy_page_range() succeeded; as VM_PAT is not set then, we won't try cleaning VM_PAT up once more and untrack_pfn() will be happy. Note that leaving these page tables in place without a reservation is not a problem, as we are aborting fork(); this process will never run. A reproducer can trigger this usually at the first try: https://gitlab.com/davidhildenbrand/scratchspace/-/raw/main/reproducers/pat_fork.c WARNING: CPU: 26 PID: 11650 at arch/x86/mm/pat/memtype.c:983 get_pat_info+0xf6/0x110 Modules linked in: ... CPU: 26 UID: 0 PID: 11650 Comm: repro3 Not tainted 6.12.0-rc5+ #92 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-2.fc40 04/01/2014 RIP: 0010:get_pat_info+0xf6/0x110 ... Call Trace: <TASK> ... untrack_pfn+0x52/0x110 unmap_single_vma+0xa6/0xe0 unmap_vmas+0x105/0x1f0 exit_mmap+0xf6/0x460 __mmput+0x4b/0x120 copy_process+0x1bf6/0x2aa0 kernel_clone+0xab/0x440 __do_sys_clone+0x66/0x90 do_syscall_64+0x95/0x180 Likely this case was missed in: d155df53f310 ("x86/mm/pat: clear VM_PAT if copy_p4d_range failed") ... and instead of undoing the reservation we simply cleared the VM_PAT flag. Keep the documentation of these functions in include/linux/pgtable.h, one place is more than sufficient -- we should clean that up for the other functions like track_pfn_remap/untrack_pfn separately.14d CVE-2025-60912—

——3——CVE-2026-639399.3 CRI

9.7%

——3In the Linux kernel, the following vulnerability has been resolved: KVM: SEV: Compute the correct max length of the in-GHCB scratch area When setting the length of the GHCB scratch area, and the area is in the GHCB shared buffer, set the effective length of the scratch area to the max possible size given the start of the guest-provided pointer, and the end of the shared buffer. The code was "fine" when first introduced, as KVM doesn't consult the length of the buffer when emulating MMIO, because the passed in @len always specifies the *max* size required. But for PSC requests, the incoming @len is just the minimum length (to process the header), and KVM needs to know the full size of the scratch area to avoid buffer overflows (spoiler alert). Opportunistically rename @len => @min_len to better reflect its role.16d CVE-2022-31226—

——3——CVE-2026-115055.0 MED

9.7%

——3A flaw has been found in GL.iNet A1300, AX1800, AXT1800, MT2500, MT3000, MT6000, X3000 and XE3000 4.8.x. This affects an unknown function of the component glnassys. Executing a manipulation can lead to use of hard-coded cryptographic key . The attack may be launched remotely. The attack requires a high level of complexity. The exploitability is reported as difficult. Upgrading to version 4.9.0 mitigates this issue. Upgrading the affected component is advised.21d CVE-2025-24623—

9.7%

——3——CVE-2025-42598—

9.7%

——3——CVE-2022-509476.4 MED

9.7%

——3WordPress Plugin Testimonial Slider and Showcase 2.2.6 contains a stored cross-site scripting vulnerability that allows authenticated editors to inject malicious scripts by failing to sanitize the post_title parameter. Attackers with editor privileges can inject JavaScript payloads through the testimonial title field that execute in the browsers of users viewing the draft post, enabling cookie theft and session hijacking.19d CVE-2026-20637—

9.7%

——3——