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-2021-0614—1.6%
——0——CVE-2026-463786.2 MED1.6%
——0Dasel is a command-line tool and library for querying, modifying, and transforming data structures. From 3.0.0 until 3.10.1, the selector lexer matchRegexPattern closure in (*Tokenizer).parseCurRune in selector/lexer/tokenize.go loops while tokenizing an unterminated regex literal such as r/ because peekRuneEqual returns false after the end of input, allowing attacker-controlled selector strings to consume CPU indefinitely. This issue is fixed in version 3.10.1.5dCVE-2021-0613—1.6%
——0——CVE-2026-530175.5 MED1.6%
——0In the Linux kernel, the following vulnerability has been resolved:
f2fs: fix data loss caused by incorrect use of nat_entry flag
Data loss can occur when fsync is performed on a newly created file
(before any checkpoint has been written) concurrently with a checkpoint
operation. The scenario is as follows:
create & write & fsync 'file A' write checkpoint
- f2fs_do_sync_file // inline inode
- f2fs_write_inode // inode folio is dirty
- f2fs_write_checkpoint
- f2fs_flush_merged_writes
- f2fs_sync_node_pages
- f2fs_flush_nat_entries
- f2fs_fsync_node_pages // no dirty node
- f2fs_need_inode_block_update // return false
SPO and lost 'file A'
f2fs_flush_nat_entries() sets the IS_CHECKPOINTED and HAS_LAST_FSYNC
flags for the nat_entry, but this does not mean that the checkpoint has
actually completed successfully. However, f2fs_need_inode_block_update()
checks these flags and incorrectly assumes that the checkpoint has
finished.
The root cause is that the semantics of IS_CHECKPOINTED and
HAS_LAST_FSYNC are only guaranteed after the checkpoint write fully
completes.
This patch modifies f2fs_need_inode_block_update() to acquire the
sbi->node_write lock before reading the nat_entry flags, ensuring that
once IS_CHECKPOINTED and HAS_LAST_FSYNC are observed to be set, the
checkpoint operation has already completed.7dCVE-2026-148013.3 LOW1.6%
——0A security vulnerability has been detected in GPAC 26.03-DEV-rev342-g80071f700-master. The impacted element is the function txtin_probe_duration of the file src/filters/load_text.c of the component TeXML File Handler. Such manipulation of the argument txml_timescale leads to divide by zero. An attack has to be approached locally. The name of the patch is 86a5191f2e750c767253e27ed6cfd6d547afebc2. A patch should be applied to remediate this issue.16dCVE-2026-151853.3 LOW1.6%
——0A vulnerability was determined in GPAC 26.03-DEV. This affects the function vobsub_read_idx of the file /src/media_tools/vobsub.c of the component MP4Box. Executing a manipulation of the argument num_langs can lead to out-of-bounds read. The attack needs to be launched locally. The exploit has been publicly disclosed and may be utilized. This patch is called 532097084729a936bcdf6a27c41003f3bd7dc3ff. It is best practice to apply a patch to resolve this issue. Two different commits were applied to fix this issue.13dCVE-2024-58059—1.6%
——0——CVE-2026-10298—1.6%
——0——CVE-2026-533807.8 HIG1.6%
——0In the Linux kernel, the following vulnerability has been resolved:
media: rzv2h-ivc: Fix concurrent buffer list access
The list of buffers (`rzv2h_ivc::buffers.queue`) is protected by a
spinlock (`rzv2h_ivc::buffers.lock`). However, in
`rzv2h_ivc_transfer_buffer()`, which runs in a separate workqueue, the
`list_del()` call is executed without holding the spinlock, which makes
it possible for the list to be concurrently modified
Fix that by removing a buffer from the list in the lock protected section.
[assign ivc->buffers.curr in critical section as reported by Barnabas]2dCVE-2026-533105.5 MED1.6%
——0In the Linux kernel, the following vulnerability has been resolved:
soc/tegra: cbb: Fix cross-fabric target timeout lookup
When a fabric receives an error interrupt, the error may have
occurred on a different fabric. The target timeout lookup was using
the wrong base address (cbb->regs) with offsets from a different
fabric's target map, causing a kernel page fault.
Unable to handle kernel paging request at virtual address ffff80000954cc00
pc : tegra234_cbb_get_tmo_slv+0xc/0x28
Call trace:
tegra234_cbb_get_tmo_slv+0xc/0x28
print_err_notifier+0x6c0/0x7d0
tegra234_cbb_isr+0xe4/0x1b4
Add tegra234_cbb_get_fabric() to look up the correct fabric device
using fab_id, and use its base address for accessing target timeout
registers.16dCVE-2024-40653—1.6%
——0——CVE-2026-533737.8 HIG1.6%
——0In the Linux kernel, the following vulnerability has been resolved:
mm/vma: do not try to unmap a VMA if mmap_prepare() invoked from mmap()
The mmap_prepare hook functionality includes the ability to invoke
mmap_prepare() from the mmap() hook of existing 'stacked' drivers, that is
ones which are capable of calling the mmap hooks of other drivers/file
systems (e.g. overlayfs, shm).
As part of the mmap_prepare action functionality, we deal with errors by
unmapping the VMA should one arise. This works in the usual mmap_prepare
case, as we invoke this action at the last moment, when the VMA is
established in the maple tree.
However, the mmap() hook passes a not-fully-established VMA pointer to the
caller (which is the motivation behind the mmap_prepare() work), which is
detached.
So attempting to unmap a VMA in this state will be problematic, with the
most obvious symptom being a warning in vma_mark_detached(), because the
VMA is already detached.
It's also unncessary - the mmap() handler will clean up the VMA on error.
So to fix this issue, this patch propagates whether or not an mmap action
is being completed via the compatibility layer or directly.
If the former, then we do not attempt VMA cleanup, if the latter, then we
do.
This patch also updates the userland VMA tests to reflect the change.2dCVE-2026-533115.5 MED1.6%
——0In the Linux kernel, the following vulnerability has been resolved:
fuse: fix uninit-value in fuse_dentry_revalidate()
fuse_dentry_revalidate() may be called with a dentry that didn't had
->d_time initialised. The issue was found with KMSAN, where lookup_open()
calls __d_alloc(), followed by d_revalidate(), as shown below:
=====================================================
BUG: KMSAN: uninit-value in fuse_dentry_revalidate+0x150/0x13d0 fs/fuse/dir.c:394
fuse_dentry_revalidate+0x150/0x13d0 fs/fuse/dir.c:394
d_revalidate fs/namei.c:1030 [inline]
lookup_open fs/namei.c:4405 [inline]
open_last_lookups fs/namei.c:4583 [inline]
path_openat+0x1614/0x64c0 fs/namei.c:4827
do_file_open+0x2aa/0x680 fs/namei.c:4859
[...]
Uninit was created at:
slab_post_alloc_hook mm/slub.c:4466 [inline]
slab_alloc_node mm/slub.c:4788 [inline]
kmem_cache_alloc_lru_noprof+0x382/0x1280 mm/slub.c:4807
__d_alloc+0x55/0xa00 fs/dcache.c:1740
d_alloc_parallel+0x99/0x2740 fs/dcache.c:2604
lookup_open fs/namei.c:4398 [inline]
open_last_lookups fs/namei.c:4583 [inline]
path_openat+0x135f/0x64c0 fs/namei.c:4827
do_file_open+0x2aa/0x680 fs/namei.c:4859
[...]
=====================================================16dCVE-2026-46153—1.6%
——0——CVE-2021-0615—1.6%
——0——CVE-2026-43174—1.6%
——0——CVE-2020-27035—1.6%
——0——CVE-2026-23194—1.6%
——0——CVE-2022-20208—1.6%
——0——CVE-2025-58999—1.6%
——0——CVE-2025-15576—1.6%
——0——CVE-2024-34729—1.6%
——0——CVE-2026-49411—1.6%
——0——CVE-2023-33029—1.6%
——0——CVE-2026-3449—1.6%
——0——CVE-2026-532507.8 HIG1.6%
——0In the Linux kernel, the following vulnerability has been resolved:
xsk: cache csum_start/csum_offset to fix TOCTOU in xsk_skb_metadata()
The TX metadata area resides in the UMEM buffer which is memory-mapped
and concurrently writable by userspace. In xsk_skb_metadata(),
csum_start and csum_offset are read from shared memory for bounds
validation, then read again for skb assignment. A malicious userspace
application can race to overwrite these values between the two reads,
bypassing the bounds check and causing out-of-bounds memory access
during checksum computation in the transmit path.
Fix this by reading csum_start and csum_offset into local variables
once, then using the local copies for both validation and assignment.
Note that other metadata fields (flags, launch_time) and the cached
csum fields may be mutually inconsistent due to concurrent userspace
writes, but this is benign: the only security-critical invariant is
that each field's validated value is the same one used, which local
caching guarantees.14dCVE-2025-64240—1.6%
——0——CVE-2022-25675—1.6%
——0——CVE-2025-32088—1.6%
——0——CVE-2022-25327—1.6%
——0——CVE-2026-7925—1.6%
——0——CVE-2025-62733—1.6%
——0——CVE-2026-508136.1 MED1.6%
——0An issue in SQLite before Fossil check-in 869a51ae84df allows a local attacker to obtain sensitive information via the Session Extension changeset concat/changegroup merge path13dCVE-2025-62103—1.6%
——0——CVE-2026-41347—1.6%
——0——CVE-2024-5464—1.6%
——0——CVE-2025-62102—1.6%
——0——CVE-2025-64256—1.6%
——0——CVE-2025-0005—1.6%
——0——CVE-2026-49358—1.6%
——0——