Vulnerabilities exploitable today
401,677in 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,754
New KEV · 24H0
Exploit Today ≥ 701,666
Distribution · last window
- Critical3,403
- High15,536
- Medium14,806
- Low1,423
Filters
Window
Severity
Flags
CVECVSSEPSSKEVRExploitTitleMod.
CVE-2023-21157—0.8%
——0——CVE-2025-58922—0.8%
——0——CVE-2025-53174—0.8%
——0——CVE-2026-643787.8 HIG0.8%
——0In the Linux kernel, the following vulnerability has been resolved:
writeback: fix race between cgroup_writeback_umount() and inode_switch_wbs()
When a container exits, the following BUG_ON() is occasionally triggered:
==================================================================
VFS: Busy inodes after unmount of sdb (ext4)
------------[ cut here ]------------
kernel BUG at fs/super.c:695!
CPU: 3 PID: 6 Comm: containerd-shim Tainted: G OE K 6.6 #1
pstate: 63400009 (nZCv daif +PAN -UAO +TCO +DIT -SSBS BTYPE=--)
pc : generic_shutdown_super+0xf0/0x100
lr : generic_shutdown_super+0xf0/0x100
Call trace:
generic_shutdown_super+0xf0/0x100
kill_block_super+0x20/0x48
ext4_kill_sb+0x28/0x60
deactivate_locked_super+0x54/0x130
deactivate_super+0x84/0xa0
cleanup_mnt+0xa4/0x140
__cleanup_mnt+0x18/0x28
task_work_run+0x78/0xe0
do_notify_resume+0x204/0x240
==================================================================
The root cause is a race between cgroup_writeback_umount() and
inode_switch_wbs()/cleanup_offline_cgwb(). There is a window between
inode_prepare_wbs_switch() returning true and the subsequent
wb_queue_isw() call. Following is the process that triggers the issue:
CPU A (umount) | CPU B (writeback)
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
inode_switch_wbs/cleanup_offline_cgwb
atomic_inc(&isw_nr_in_flight)
inode_prepare_wbs_switch
-> passes SB_ACTIVE check
__iget(inode)
generic_shutdown_super
sb->s_flags &= ~SB_ACTIVE
cgroup_writeback_umount(sb)
smp_mb()
atomic_read(&isw_nr_in_flight)
rcu_barrier()
-> no pending RCU callbacks
flush_workqueue(isw_wq)
-> nothing queued, returns
evict_inodes(sb)
-> Inode skipped as isw still holds a ref.
sop->put_super(sb)
/* destroys percpu counters */
-> VFS: Busy inodes after unmount!
wb_queue_isw()
queue_work(isw_wq, ...)
/* later in work function */
inode_switch_wbs_work_fn
process_inode_switch_wbs
iput() -> evict
percpu_counter_dec() // UAF!
Fix this by extending the RCU read-side critical section in
inode_switch_wbs() and cleanup_offline_cgwb() to cover from
inode_prepare_wbs_switch() through wb_queue_isw(). Since there is
no sleep in this window, rcu_read_lock() can be used. Then add a
synchronize_rcu() in cgroup_writeback_umount() before the existing
rcu_barrier(), so that all in-flight switchers that have passed the
SB_ACTIVE check have completed queue_work() before flush_workqueue()
is called.
The existing rcu_barrier() is intentionally retained so this fix can
be backported unchanged to stable kernels (5.10.y, 6.6.y, ...) that
still queue switches via queue_rcu_work(). It is a no-op on current
mainline (since commit e1b849cfa6b6 ("writeback: Avoid contention on
wb->list_lock when switching inodes")) and is removed in a follow-up
patch.3dCVE-2025-27701—0.8%
——0——CVE-2024-31334—0.8%
——0——CVE-2026-638587.8 HIG0.8%
——0In the Linux kernel, the following vulnerability has been resolved:
netfilter: nf_tables: add hook transactions for device deletions
Restore the flag that indicates that the hook is going away, ie.
NFT_HOOK_REMOVE, but add a new transaction object to track deletion
of hooks without altering the basechain/flowtable hook_list during
the preparation phase.
The existing approach that moves the hook from the basechain/flowtable
hook_list to transaction hook_list breaks netlink dump path readers
of this RCU-protected list.
It should be possible use an array for nft_trans_hook to store the
deleted hooks to compact the representation but I am not expecting
many hook object, specially now that wildcard support for devices
is in place.
Note that the nft_trans_chain_hooks() list contains a list of struct
nft_trans_hook objects for DELCHAIN and DELFLOWTABLE commands, while
this list stores struct nft_hook objects for NEWCHAIN and NEWFLOWTABLE.
Note that new commands can be updated to use nft_trans_hook for
consistency.
This patch also adapts the event notification path to deal with the list
of hook transactions.3dCVE-2026-43854—0.8%
——0A vulnerability could allow an attacker with access to an encrypted project file to retrieve administrator credentials for EdgeLink-enabled devices.2dCVE-2026-927455.0 MED0.8%
——0A flaw was found in cockpit-machines. This vulnerability allows a local attacker with the ability to inspect process metadata to disclose a sensitive Red Hat Subscription Management (RHSM) offline token. The token is exposed when it is passed as a command-line argument to a helper script during the token validation process. Successful exploitation could lead to the compromise of confidentiality, as the exposed token can be used to request access tokens.30dCVE-2026-942875.5 MED0.8%
——0A denial of service via unsigned underflow in libXpm's write path in libXpm before 3.5.19 could be used by local attackers to cause unbounded CPU usage and memory exhaustion.23dCVE-2026-234667.8 HIG0.8%
——0In the Linux kernel, the following vulnerability has been resolved:
drm/xe: Open-code GGTT MMIO access protection
GGTT MMIO access is currently protected by hotplug (drm_dev_enter),
which works correctly when the driver loads successfully and is later
unbound or unloaded. However, if driver load fails, this protection is
insufficient because drm_dev_unplug() is never called.
Additionally, devm release functions cannot guarantee that all BOs with
GGTT mappings are destroyed before the GGTT MMIO region is removed, as
some BOs may be freed asynchronously by worker threads.
To address this, introduce an open-coded flag, protected by the GGTT
lock, that guards GGTT MMIO access. The flag is cleared during the
dev_fini_ggtt devm release function to ensure MMIO access is disabled
once teardown begins.
(cherry picked from commit 4f3a998a173b4325c2efd90bdadc6ccd3ad9a431)3dCVE-2024-47935—0.8%
——0——CVE-2022-32638—0.8%
——0——CVE-2026-1051184.7 MED0.8%
——0OpenAM before 16.1.3 contains an open redirect vulnerability that allows unauthenticated attackers to redirect users by supplying an unverified id_token_hint to the /oauth2/connect/endSession endpoint. Attackers can name any realm client in a forged hint to redirect victims to any registered post-logout URI, enabling phishing that borrows the OpenAM host's trust.16dCVE-2026-1099764.7 MED0.8%
——0A flaw was found in the clevis PKCS#11 pin. The clevis-pkcs11-afunix-socket-unlock daemon crashes when an AF_UNIX client connects to the data socket without a bound address, due to an integer underflow in the getpeername result handling. This causes a denial of service, preventing LUKS disk decryption from completing during boot.7dCVE-2024-58117—0.8%
——0——CVE-2026-113086.3 MED0.8%
——0Inappropriate implementation in Extensions in Google Chrome prior to 149.0.7827.53 allowed an attacker who convinced a user to install a malicious extension to perform privilege escalation via a crafted Chrome Extension. (Chromium security severity: Low)92dCVE-2024-25991—0.8%
——0——CVE-2022-20316—0.8%
——0——CVE-2022-20307—0.8%
——0——CVE-2026-640317.8 HIG0.8%
——0In the Linux kernel, the following vulnerability has been resolved:
erofs: fix managed cache race for unaligned extents
After unaligned compressed extents were introduced, the following race
could occur:
[Thread 1] [Thread 2]
(z_erofs_fill_bio_vec)
<handle a Z_EROFS_PREALLOCATED_FOLIO folio>
...
filemap_add_folio (1)
(z_erofs_bind_cache)
<the same folio is found..>
..
..
folio_attach_private (2)
filemap_add_folio (3) again
Since (1) is executed but (2) hasn't been executed yet, it's possible
that another thread finds the same managed folio in z_erofs_bind_cache()
for a different pcluster and calls filemap_add_folio() again since
folio->private is still Z_EROFS_PREALLOCATED_FOLIO.
Fix this by explicitly clearing folio->private before making the folio
visible in the managed cache so that another pcluster can simply wait
on the locked managed folio as what we did for other shared cases [1].
This only impacts unaligned data compression (`-E48bit` with zstd,
for example).
[1] Commit 9e2f9d34dd12 ("erofs: handle overlapped pclusters out of
crafted images properly") was originally introduced to handle crafted
overlapped extents, but it addresses unaligned extents as well.9dCVE-2022-39119—0.8%
——0——CVE-2023-48408—0.8%
——0——CVE-2026-16769—0.8%
——0An unencrypted 'pause encryption request' message causes a denial of service in the in the RS9116W/SiWx917. See vulnerability B-E10 in the related paper below.44dCVE-2022-47341—0.8%
——0——CVE-2022-20442—0.8%
——0——CVE-2024-33037—0.8%
——0——CVE-2023-48399—0.8%
——0——CVE-2023-20740—0.8%
——0——CVE-2022-21777—0.8%
——0——CVE-2025-623383.3 LOW0.8%
——0HCL BigFix Cloud Lifecycle Management is affected by lack of input validation. This low-level flaw allows unauthorized access and may lead to information exposure.92dCVE-2023-32809—0.8%
——0——CVE-2026-196536.5 MED0.8%
——0IBM AIX 7.2, and 7.3 and IBM PowerVM VIOS 4.1 could allow a local attacker to cause a denial of service due to improper handling of memory page table configurations.58dCVE-2025-647407.5 HIG0.8%
——0Improper verification of cryptographic signature in the installer for Zoom Workplace VDI Client for Windows may allow an authenticated user to conduct an escalation of privilege via local access.4dCVE-2024-0041—0.8%
——0——CVE-2022-26435—0.8%
——0——CVE-2023-21652—0.8%
——0——CVE-2022-20252—0.8%
——0——CVE-2025-27061—0.8%
——0——CVE-2023-48422—0.8%
——0——