Vulnerabilities exploitable today
364,588in 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,675
New KEV · 24H0
Exploit Today ≥ 701,620
Distribution · last window
- Critical2,394
- High10,137
- Medium5,050
- Low465
Window
Severity
Flags
CVECVSSEPSSKEVRExploitTitleMod.
CVE-2025-43239—13.7%
——4——CVE-2025-42897—13.7%
——4——CVE-2025-21726—13.7%
——4——CVE-2023-20251—13.7%
——4——CVE-2025-53927—13.7%
——4——CVE-2022-3967—13.7%
——4——CVE-2025-25943—13.7%
——4——CVE-2025-8290—13.7%
——4——CVE-2022-48855—13.7%
——4——CVE-2024-42290—13.7%
——4——CVE-2025-42912—13.7%
——4——CVE-2024-52613—13.7%
——4——CVE-2025-8689—13.7%
——4——CVE-2024-50147—13.7%
——4——CVE-2024-358587.8 HIG13.7%
——4In the Linux kernel, the following vulnerability has been resolved:
net: bcmasp: fix memory leak when bringing down interface
When bringing down the TX rings we flush the rings but forget to
reclaimed the flushed packets. This leads to a memory leak since we
do not free the dma mapped buffers. This also leads to tx control
block corruption when bringing down the interface for power
management.22dCVE-2024-5557—13.7%
——4——CVE-2025-1430—13.7%
——4——CVE-2025-1651—13.7%
——4——CVE-2024-449497.8 HIG13.7%
——4In the Linux kernel, the following vulnerability has been resolved:
parisc: fix a possible DMA corruption
ARCH_DMA_MINALIGN was defined as 16 - this is too small - it may be
possible that two unrelated 16-byte allocations share a cache line. If
one of these allocations is written using DMA and the other is written
using cached write, the value that was written with DMA may be
corrupted.
This commit changes ARCH_DMA_MINALIGN to be 128 on PA20 and 32 on PA1.1 -
that's the largest possible cache line size.
As different parisc microarchitectures have different cache line size, we
define arch_slab_minalign(), cache_line_size() and
dma_get_cache_alignment() so that the kernel may tune slab cache
parameters dynamically, based on the detected cache line size.22dCVE-2025-20080—13.7%
——4——CVE-2020-255027.8 HIG13.7%
——4Cybereason EDR version 19.1.282 and above, 19.2.182 and above, 20.1.343 and above, and 20.2.X and above has a DLL hijacking vulnerability, which could allow a local attacker to execute code with elevated privileges.48dCVE-2024-13811—13.7%
——4——CVE-2023-52889—13.7%
——4——CVE-2025-1429—13.7%
——4——CVE-2023-53977—13.7%
——4——CVE-2022-37877—13.7%
——4——CVE-2025-8150—13.7%
——4——CVE-2026-32717—13.7%
——4——CVE-2024-268308.4 HIG13.7%
——4In the Linux kernel, the following vulnerability has been resolved:
i40e: Do not allow untrusted VF to remove administratively set MAC
Currently when PF administratively sets VF's MAC address and the VF
is put down (VF tries to delete all MACs) then the MAC is removed
from MAC filters and primary VF MAC is zeroed.
Do not allow untrusted VF to remove primary MAC when it was set
administratively by PF.
Reproducer:
1) Create VF
2) Set VF interface up
3) Administratively set the VF's MAC
4) Put VF interface down
[root@host ~]# echo 1 > /sys/class/net/enp2s0f0/device/sriov_numvfs
[root@host ~]# ip link set enp2s0f0v0 up
[root@host ~]# ip link set enp2s0f0 vf 0 mac fe:6c:b5:da:c7:7d
[root@host ~]# ip link show enp2s0f0
23: enp2s0f0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP mode DEFAULT group default qlen 1000
link/ether 3c:ec:ef:b7:dd:04 brd ff:ff:ff:ff:ff:ff
vf 0 link/ether fe:6c:b5:da:c7:7d brd ff:ff:ff:ff:ff:ff, spoof checking on, link-state auto, trust off
[root@host ~]# ip link set enp2s0f0v0 down
[root@host ~]# ip link show enp2s0f0
23: enp2s0f0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP mode DEFAULT group default qlen 1000
link/ether 3c:ec:ef:b7:dd:04 brd ff:ff:ff:ff:ff:ff
vf 0 link/ether 00:00:00:00:00:00 brd ff:ff:ff:ff:ff:ff, spoof checking on, link-state auto, trust off22dCVE-2023-52457—13.7%
——4——CVE-2020-12894—13.7%
——4——CVE-2022-49134—13.7%
——4——CVE-2026-150855.4 MED13.7%
——4Improper Neutralization of Input During Web Page Generation ("Cross-site Scripting") vulnerability in Drupal AI SEO/GEO Analyzer allows Stored XSS. This issue affects AI SEO/GEO Analyzer versions: from 0.0.0 to 1.1.3.19dCVE-2023-53890—13.7%
——4——CVE-2024-53741—13.7%
——4——CVE-2024-2104—13.7%
——4——CVE-2024-51930—13.7%
——4——CVE-2024-56583—13.7%
——4——CVE-2023-525727.8 HIG13.7%
——4In the Linux kernel, the following vulnerability has been resolved:
cifs: Fix UAF in cifs_demultiplex_thread()
There is a UAF when xfstests on cifs:
BUG: KASAN: use-after-free in smb2_is_network_name_deleted+0x27/0x160
Read of size 4 at addr ffff88810103fc08 by task cifsd/923
CPU: 1 PID: 923 Comm: cifsd Not tainted 6.1.0-rc4+ #45
...
Call Trace:
<TASK>
dump_stack_lvl+0x34/0x44
print_report+0x171/0x472
kasan_report+0xad/0x130
kasan_check_range+0x145/0x1a0
smb2_is_network_name_deleted+0x27/0x160
cifs_demultiplex_thread.cold+0x172/0x5a4
kthread+0x165/0x1a0
ret_from_fork+0x1f/0x30
</TASK>
Allocated by task 923:
kasan_save_stack+0x1e/0x40
kasan_set_track+0x21/0x30
__kasan_slab_alloc+0x54/0x60
kmem_cache_alloc+0x147/0x320
mempool_alloc+0xe1/0x260
cifs_small_buf_get+0x24/0x60
allocate_buffers+0xa1/0x1c0
cifs_demultiplex_thread+0x199/0x10d0
kthread+0x165/0x1a0
ret_from_fork+0x1f/0x30
Freed by task 921:
kasan_save_stack+0x1e/0x40
kasan_set_track+0x21/0x30
kasan_save_free_info+0x2a/0x40
____kasan_slab_free+0x143/0x1b0
kmem_cache_free+0xe3/0x4d0
cifs_small_buf_release+0x29/0x90
SMB2_negotiate+0x8b7/0x1c60
smb2_negotiate+0x51/0x70
cifs_negotiate_protocol+0xf0/0x160
cifs_get_smb_ses+0x5fa/0x13c0
mount_get_conns+0x7a/0x750
cifs_mount+0x103/0xd00
cifs_smb3_do_mount+0x1dd/0xcb0
smb3_get_tree+0x1d5/0x300
vfs_get_tree+0x41/0xf0
path_mount+0x9b3/0xdd0
__x64_sys_mount+0x190/0x1d0
do_syscall_64+0x35/0x80
entry_SYSCALL_64_after_hwframe+0x46/0xb0
The UAF is because:
mount(pid: 921) | cifsd(pid: 923)
-------------------------------|-------------------------------
| cifs_demultiplex_thread
SMB2_negotiate |
cifs_send_recv |
compound_send_recv |
smb_send_rqst |
wait_for_response |
wait_event_state [1] |
| standard_receive3
| cifs_handle_standard
| handle_mid
| mid->resp_buf = buf; [2]
| dequeue_mid [3]
KILL the process [4] |
resp_iov[i].iov_base = buf |
free_rsp_buf [5] |
| is_network_name_deleted [6]
| callback
1. After send request to server, wait the response until
mid->mid_state != SUBMITTED;
2. Receive response from server, and set it to mid;
3. Set the mid state to RECEIVED;
4. Kill the process, the mid state already RECEIVED, get 0;
5. Handle and release the negotiate response;
6. UAF.
It can be easily reproduce with add some delay in [3] - [6].
Only sync call has the problem since async call's callback is
executed in cifsd process.
Add an extra state to mark the mid state to READY before wakeup the
waitter, then it can get the resp safely.22dCVE-2025-0393—13.7%
——4——