Vulnerabilities exploitable today
351,724in 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,651
New KEV · 24H0
Exploit Today ≥ 701,587
Distribution · last window
- Critical1,765
- High5,628
- Medium4,518
- Low412
Window
Severity
Flags
CVECVSSEPSSKEVRExploitTitleMod.
CVE-2026-31390—1.7%
——1——CVE-2016-20091—1.7%
——1——CVE-2024-43101—1.7%
——1——CVE-2026-2903—1.7%
——1——CVE-2026-638638.8 HIG1.7%
——1In the Linux kernel, the following vulnerability has been resolved:
drm/gpusvm: Fix unbalanced unlock in drm_gpusvm_scan_mm()
There is a unbalanced lock/unlock to gpusvm notifier lock:
[ 931.045868] =====================================
[ 931.046509] WARNING: bad unlock balance detected!
[ 931.047149] 6.19.0-rc6+xe-**************** #9 Tainted: G U
[ 931.048150] -------------------------------------
[ 931.048790] kworker/u5:0/51 is trying to release lock (&gpusvm->notifier_lock) at:
[ 931.049801] [<ffffffffa090c0d8>] drm_gpusvm_scan_mm+0x188/0x460 [drm_gpusvm_helper]
[ 931.050802] but there are no more locks to release!
[ 931.051463]
The drm_gpusvm_notifier_unlock() sits under err_free label and the
first jump to err_free is just before calling the
drm_gpusvm_notifier_lock() causing unbalanced unlock.2dCVE-2025-10222—1.7%
——1——CVE-2026-23162—1.7%
——1——CVE-2026-50573—1.7%
——1——CVE-2025-22394—1.7%
——1——CVE-2026-613785.5 MED1.7%
——1A divide-by-zero vulnerability in the Productivity Suite allows a local
attacker to cause a division by zero leading to a system crash.5dCVE-2025-52783—1.7%
——1——CVE-2025-52784—1.7%
——1——CVE-2025-48077—1.7%
——1——CVE-2025-62934—1.7%
——1——CVE-2026-139145.5 MED1.7%
——1Inappropriate implementation in Passwords in Google Chrome on Mac prior to 150.0.7871.47 allowed a local attacker to obtain potentially sensitive information from process memory via a malicious file. (Chromium security severity: Medium)21dCVE-2025-52794—1.7%
——1——CVE-2026-23201—1.7%
——1——CVE-2026-23225—1.7%
——1——CVE-2023-23436—1.7%
——1——CVE-2026-44972—1.7%
——1——CVE-2025-5941—1.7%
——1——CVE-2025-27904—1.7%
——1——CVE-2026-54030—1.7%
——1——CVE-2026-35180—1.7%
——1——CVE-2026-23219—1.7%
——1——CVE-2026-0106—1.7%
——1——CVE-2025-36018—1.7%
——1——CVE-2026-23215—1.7%
——1——CVE-2026-43346—1.7%
——1——CVE-2026-462955.5 MED1.7%
——1In the Linux kernel, the following vulnerability has been resolved:
KVM: x86: Do IRR scan in __kvm_apic_update_irr even if PIR is empty
Fall back to apic_find_highest_vector() when PID.ON is set but PIR
turns out to be empty, to correctly report the highest pending interrupt
from the existing IRR.
In a nested VM stress test, the following WARNING fires in
vmx_check_nested_events() when kvm_cpu_has_interrupt() reports a pending
interrupt but the subsequent kvm_apic_has_interrupt() (which invokes
vmx_sync_pir_to_irr() again) returns -1:
WARNING: CPU: 99 PID: 57767 at arch/x86/kvm/vmx/nested.c:4449 vmx_check_nested_events+0x6bf/0x6e0 [kvm_intel]
Call Trace:
kvm_check_and_inject_events
vcpu_enter_guest.constprop.0
vcpu_run
kvm_arch_vcpu_ioctl_run
kvm_vcpu_ioctl
__x64_sys_ioctl
do_syscall_64
entry_SYSCALL_64_after_hwframe
The root cause is a race between vmx_sync_pir_to_irr() on the target vCPU
and __vmx_deliver_posted_interrupt() on a sender vCPU. The sender
performs two individually-atomic operations that are not a single
transaction:
1. pi_test_and_set_pir(vector) -- sets the PIR bit
2. pi_test_and_set_on() -- sets PID.ON
The following interleaving triggers the bug:
Sender vCPU (IPI): Target vCPU (1st sync_pir_to_irr):
B1: set PIR[vector]
A1: pi_clear_on()
A2: pi_harvest_pir() -> sees B1 bit
A3: xchg() -> consumes bit, PIR=0
(1st sync returns correct max_irr)
B2: set PID.ON = 1
Target vCPU (2nd sync_pir_to_irr):
C1: pi_test_on() -> TRUE (from B2)
C2: pi_clear_on() -> ON=0
C3: pi_harvest_pir() -> PIR empty
C4: *max_irr = -1, early return
IRR NOT SCANNED
The interrupt is not lost (it resides in the IRR from the first sync and
is recovered on the next vcpu_enter_guest() iteration), but the incorrect
max_irr causes a spurious WARNING and a wasted L2 VM-Enter/VM-Exit cycle.14dCVE-2026-23421—1.7%
——1——CVE-2026-28686—1.7%
——1——CVE-2022-20438—1.7%
——1——CVE-2022-20439—1.7%
——1——CVE-2026-32443—1.7%
——1——CVE-2026-23104—1.7%
——1——CVE-2022-20212—1.7%
——1——CVE-2021-0656—1.7%
——1——CVE-2021-0655—1.7%
——1——CVE-2025-20149—1.7%
——1——