Vulnerabilities exploitable today
378,004in 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,716
New KEV · 24H0
Exploit Today ≥ 701,651
Distribution · last window
- Critical2,292
- High8,399
- Medium6,682
- Low748
Filters
Window
Severity
Flags
CVECVSSEPSSKEVRExploitTitleMod.
CVE-2026-54194—31.4%
——9——CVE-2026-537057.6 HIG31.4%
——9A flaw was found in GStreamer's WavPack audio decoder in gst-plugins-good. When processing a specially crafted WavPack file, an integer overflow in the buffer size calculation (4 * block_samples * channels) in gst_wavpack_dec_handle_frame() causes a very small heap allocation. The WavPack library then writes decoded audio samples far beyond the allocated buffer, resulting in heap memory corruption. This affects both 32-bit and 64-bit systems since the arithmetic is performed in 32-bit integers before promotion to the allocation size type. A remote attacker could use this flaw to crash an application or potentially execute arbitrary code by convincing a user to open a malicious WavPack audio file.49dCVE-2025-13126—31.4%
——9——CVE-2026-38991—31.4%
——9——CVE-2025-29838—31.4%
——9——CVE-2024-5218—31.4%
——9——CVE-2025-59511—31.4%
——9——CVE-2025-57770—31.4%
——9——CVE-2024-1133—31.4%
——9——CVE-2026-25429—31.4%
——9——CVE-2026-281499.8 CRI31.4%
——9Unauthenticated PHP Object Injection in Headless Single Sign On <= 1.6 versions.37dCVE-2024-29767—31.4%
——9——CVE-2026-58196—31.4%
——9——CVE-2026-27095—31.4%
——9——CVE-2026-3339—31.4%
——9——CVE-2021-4333—31.4%
——9——CVE-2010-3542—31.4%
——9——CVE-2026-85588—31.4%
——9phpMyFAQ versions before 4.1.8 include live TOTP shared secrets in plaintext within user data export ZIP files. Attackers obtaining exported archives can extract the TOTP seed and generate valid one-time codes to bypass two-factor authentication.7dCVE-2026-805899.8 CRI31.4%
——9In the Linux kernel, the following vulnerability has been resolved:
block: stop the timeout timer when releasing a never added disk
disk_release() undoes blk_mq_init_allocated_queue() for a disk whose
probe failed before add_disk(), but it only calls blk_mq_exit_queue().
Nothing there stops q->timeout, and that timer rolls forward: it stays
pending until it next expires, not until the last request completes.
So if the driver issued any I/O before adding the disk, the
request_queue is freed while still linked into a timer wheel bucket.
Commit 6f8191fdf41d ("block: simplify disk shutdown") dropped the
blk_cleanup_queue() call that used to stop it. __del_gendisk() and
blk_mq_destroy_queue() still do; only the probe failure path lost it.
nvme gets there because nvme_update_ns_info() submits Report Zones or
FDP io-mgmt-recv on ns->queue before the disk is added, so a later
failure - a concurrent reset setting NVME_CTRL_FROZEN, or
device_add_disk() failing - lands in put_disk() with the timer armed:
BUG: KASAN: slab-use-after-free in detach_if_pending+0x30c/0x340
Write of size 8 at addr ffff888004d71310 by task kworker/u8:2/37
__timer_delete_sync+0x156/0x240 kernel/time/timer.c:1621
blk_sync_queue+0x22/0x40 block/blk-core.c:222
nvme_sync_queues+0x100/0x150 drivers/nvme/host/core.c:5362
nvme_reset_work+0x138/0x930 drivers/nvme/host/pci.c:3264
Allocated by task 34:
__blk_mq_alloc_disk+0x33/0x100 block/blk-mq.c:4462
nvme_alloc_ns+0x290/0x3870 drivers/nvme/host/core.c:4146
Freed by task 0:
blk_free_queue_rcu+0x3a/0x50 block/blk-core.c:254
rcu_core+0xc10/0x1730 kernel/rcu/tree.c:2857
The queue being synced there is ctrl->admin_q, only a victim sharing a
timer wheel bucket with the freed queue's dangling entry; other runs
tripped in enqueue_timer(), __run_timers() or blk_mq_timeout_work().
Failing nvme_alloc_ns() with a debug patch makes it deterministic: one
leaked timer trips KASAN within seconds, while 1987 patched releases
produced no splat.
Stop the timer and the queue work items before blk_mq_exit_queue(), like
blk_mq_destroy_queue() does.
Found by FuzzNvme.25dCVE-2018-17957—31.4%
——9——CVE-2025-60991—31.4%
——9——CVE-2017-10168—31.4%
——9——CVE-2026-27437—31.4%
——9——CVE-2023-6897—31.4%
——9——CVE-2026-46849—31.4%
——9——CVE-2025-14169—31.4%
——9——CVE-2024-28002—31.4%
——9——CVE-2026-27439—31.4%
——9——CVE-2024-4886—31.4%
——9——CVE-2023-6731—31.4%
——9——CVE-2009-0310—31.4%
——9——CVE-2022-23790—31.4%
——9——CVE-2024-6026—31.4%
——9——CVE-2024-54171—31.4%
——9——CVE-2022-30687—31.4%
——9——CVE-2025-54111—31.4%
——9——CVE-2023-20082—31.4%
——9——CVE-2026-423917.5 HIG31.4%
——9An unauthenticated attacker can send an IMAP ID command with a very large number of parameters before logging in, which causes memory and CPU usage to grow disproportionately. The login process can be terminated by the out-of-memory handling, which also terminates all other connections handled by the same process. This can cause degradation or denial of service for IMAP logins. Limit the number of connections handled by a single imap-login process. This has a performance impact though. Update to non-vulnerable version. No publicly available exploits are known.18dCVE-2026-25032—31.4%
——9——CVE-2020-5966—31.4%
——9——