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-2025-52794—1.7%
——1——CVE-2026-23201—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-48077—1.7%
——1——CVE-2025-22394—1.7%
——1——CVE-2026-43477—1.7%
——1——CVE-2025-49218—1.7%
——1——CVE-2026-23162—1.7%
——1——CVE-2026-23384—1.7%
——1——CVE-2026-50573—1.7%
——1——CVE-2024-40682—1.7%
——1——CVE-2026-23225—1.7%
——1——CVE-2021-0656—1.7%
——1——CVE-2026-23215—1.7%
——1——CVE-2026-462975.5 MED1.7%
——1In the Linux kernel, the following vulnerability has been resolved:
net: libwx: use request_irq for VF misc interrupt
Currently, request_threaded_irq() is used with a primary handler but a
NULL threaded handler, while also setting the IRQF_ONESHOT flag. This
specific combination triggers a WARNING since the commit aef30c8d569c
("genirq: Warn about using IRQF_ONESHOT without a threaded handler").
WARNING: kernel/irq/manage.c:1502 at __setup_irq+0x4fa/0x760
Fix the issue by switching to request_irq(), which is the appropriate
interface or a non-threaded interrupt handler, and removing the
unnecessary IRQF_ONESHOT flag.14dCVE-2021-0898—1.7%
——1——CVE-2026-23421—1.7%
——1——CVE-2026-23104—1.7%
——1——CVE-2026-28686—1.7%
——1——CVE-2021-0655—1.7%
——1——CVE-2026-32443—1.7%
——1——CVE-2022-20439—1.7%
——1——CVE-2026-43346—1.7%
——1——CVE-2022-20438—1.7%
——1——CVE-2025-20149—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-2025-52792—1.7%
——1——CVE-2022-20212—1.7%
——1——CVE-2021-39814—1.7%
——1——CVE-2026-43337—1.7%
——1——CVE-2026-43118—1.7%
——1——CVE-2026-43463—1.7%
——1——CVE-2026-4009—1.7%
——1——CVE-2025-27559—1.7%
——1——CVE-2025-23302—1.7%
——1——CVE-2025-23301—1.7%
——1——CVE-2024-36501—1.7%
——1——CVE-2026-22735—1.7%
——1——CVE-2025-49211—1.7%
——1——CVE-2025-43522—1.7%
——1——