Vulnerabilities exploitable today
367,284in 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,687
New KEV · 24H0
Exploit Today ≥ 701,629
Distribution · last window
- Critical2,295
- High9,357
- Medium5,357
- Low528
Window
Severity
Flags
CVECVSSEPSSKEVRExploitTitleMod.
CVE-2024-35639—17.6%
——5——CVE-2025-43224—17.6%
——5——CVE-2023-47686—17.6%
——5——CVE-2020-12980—17.6%
——5——CVE-2021-20188—17.6%
——5——CVE-2021-47769—17.6%
——5——CVE-2023-47645—17.6%
——5——CVE-2024-7259—17.6%
——5——CVE-2024-47387—17.6%
——5——CVE-2024-34385—17.6%
——5——CVE-2024-49293—17.6%
——5——CVE-2025-68723—17.6%
——5——CVE-2024-27255—17.6%
——5——CVE-2024-39836—17.6%
——5——CVE-2025-4597—17.6%
——5——CVE-2022-45491—17.6%
——5——CVE-2026-46871—17.6%
——5——CVE-2026-357176.3 MED17.6%
——5A stack-based buffer overflow in the export_language.cgi binary in VIVOTEK FD8136 firmware FD8136-VVTK-0300a allows authenticated remote attackers to execute arbitrary code as root via a crafted POST request to the /cgi-bin/admin/export_language.cgi endpoint. The handler passes the attacker-controlled Content-Length value directly to fread() as the read size into a fixed-size 0x60-byte stack buffer, overwriting the saved link register. The binary is compiled without stack canaries.41dCVE-2018-25309—17.6%
——5——CVE-2023-41926—17.6%
——5——CVE-2026-149673.1 LOW17.6%
——5BBOT's `github_workflows` module could be induced to write a downloaded artifact outside its configured output directory: its path-containment check did not resolve `..`, so a crafted `CODE_REPOSITORY` URL could traverse out of the intended folder. The write is bounded to two directory levels above the output location and its target is determined by the operator's configuration, not the attacker.13dCVE-2025-463985.5 MED17.6%
——5In xfig diagramming tool, a stack-overflow while running fig2dev allows memory corruption via local input manipulation via read_objects function.63dCVE-2026-59036.5 MED17.6%
——5Policy bypass in IFrameSandbox in Google Chrome prior to 147.0.7727.55 allowed a remote attacker who convinced a user to engage in specific UI gestures to bypass navigation restrictions via a crafted HTML page. (Chromium security severity: Low)39dCVE-2024-45769—17.6%
——5——CVE-2026-24831—17.6%
——5——CVE-2024-50431—17.6%
——5——CVE-2025-46749—17.6%
——5——CVE-2024-47647—17.6%
——5——CVE-2026-34306—17.6%
——5——CVE-2024-269767.8 HIG17.6%
——5In the Linux kernel, the following vulnerability has been resolved:
KVM: Always flush async #PF workqueue when vCPU is being destroyed
Always flush the per-vCPU async #PF workqueue when a vCPU is clearing its
completion queue, e.g. when a VM and all its vCPUs is being destroyed.
KVM must ensure that none of its workqueue callbacks is running when the
last reference to the KVM _module_ is put. Gifting a reference to the
associated VM prevents the workqueue callback from dereferencing freed
vCPU/VM memory, but does not prevent the KVM module from being unloaded
before the callback completes.
Drop the misguided VM refcount gifting, as calling kvm_put_kvm() from
async_pf_execute() if kvm_put_kvm() flushes the async #PF workqueue will
result in deadlock. async_pf_execute() can't return until kvm_put_kvm()
finishes, and kvm_put_kvm() can't return until async_pf_execute() finishes:
WARNING: CPU: 8 PID: 251 at virt/kvm/kvm_main.c:1435 kvm_put_kvm+0x2d/0x320 [kvm]
Modules linked in: vhost_net vhost vhost_iotlb tap kvm_intel kvm irqbypass
CPU: 8 PID: 251 Comm: kworker/8:1 Tainted: G W 6.6.0-rc1-e7af8d17224a-x86/gmem-vm #119
Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 0.0.0 02/06/2015
Workqueue: events async_pf_execute [kvm]
RIP: 0010:kvm_put_kvm+0x2d/0x320 [kvm]
Call Trace:
<TASK>
async_pf_execute+0x198/0x260 [kvm]
process_one_work+0x145/0x2d0
worker_thread+0x27e/0x3a0
kthread+0xba/0xe0
ret_from_fork+0x2d/0x50
ret_from_fork_asm+0x11/0x20
</TASK>
---[ end trace 0000000000000000 ]---
INFO: task kworker/8:1:251 blocked for more than 120 seconds.
Tainted: G W 6.6.0-rc1-e7af8d17224a-x86/gmem-vm #119
"echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
task:kworker/8:1 state:D stack:0 pid:251 ppid:2 flags:0x00004000
Workqueue: events async_pf_execute [kvm]
Call Trace:
<TASK>
__schedule+0x33f/0xa40
schedule+0x53/0xc0
schedule_timeout+0x12a/0x140
__wait_for_common+0x8d/0x1d0
__flush_work.isra.0+0x19f/0x2c0
kvm_clear_async_pf_completion_queue+0x129/0x190 [kvm]
kvm_arch_destroy_vm+0x78/0x1b0 [kvm]
kvm_put_kvm+0x1c1/0x320 [kvm]
async_pf_execute+0x198/0x260 [kvm]
process_one_work+0x145/0x2d0
worker_thread+0x27e/0x3a0
kthread+0xba/0xe0
ret_from_fork+0x2d/0x50
ret_from_fork_asm+0x11/0x20
</TASK>
If kvm_clear_async_pf_completion_queue() actually flushes the workqueue,
then there's no need to gift async_pf_execute() a reference because all
invocations of async_pf_execute() will be forced to complete before the
vCPU and its VM are destroyed/freed. And that in turn fixes the module
unloading bug as __fput() won't do module_put() on the last vCPU reference
until the vCPU has been freed, e.g. if closing the vCPU file also puts the
last reference to the KVM module.
Note that kvm_check_async_pf_completion() may also take the work item off
the completion queue and so also needs to flush the work queue, as the
work will not be seen by kvm_clear_async_pf_completion_queue(). Waiting
on the workqueue could theoretically delay a vCPU due to waiting for the
work to complete, but that's a very, very small chance, and likely a very
small delay. kvm_arch_async_page_present_queued() unconditionally makes a
new request, i.e. will effectively delay entering the guest, so the
remaining work is really just:
trace_kvm_async_pf_completed(addr, cr2_or_gpa);
__kvm_vcpu_wake_up(vcpu);
mmput(mm);
and mmput() can't drop the last reference to the page tables if the vCPU is
still alive, i.e. the vCPU won't get stuck tearing down page tables.
Add a helper to do the flushing, specifically to deal with "wakeup all"
work items, as they aren't actually work items, i.e. are never placed in a
workqueue. Trying to flush a bogus workqueue entry rightly makes
__flush_work() complain (kudos to whoever added that sanity check).
Note, commit 5f6de5cbebee ("KVM: Prevent module exit until al
---truncated---28dCVE-2022-491355.5 MED17.6%
——5In the Linux kernel, the following vulnerability has been resolved:
drm/amd/display: Fix memory leak
[why]
Resource release is needed on the error handling path
to prevent memory leak.
[how]
Fix this by adding kfree on the error handling path.20dCVE-2025-68429—17.6%
——5——CVE-2026-3111—17.6%
——5——CVE-2025-67715—17.6%
——5——CVE-2020-7307—17.6%
——5——CVE-2026-33422—17.6%
——5——CVE-2026-1919—17.6%
——5——CVE-2025-47184—17.6%
——5——CVE-2026-34299—17.6%
——5——CVE-2024-40934—17.6%
——5——