Vulnerabilities exploitable today
366,194in 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,682
New KEV · 24H0
Exploit Today ≥ 701,626
Distribution · last window
- Critical2,415
- High10,330
- Medium5,246
- Low512
Window
Severity
Flags
CVECVSSEPSSKEVRExploitTitleMod.
CVE-2022-29093—15.1%
——5——CVE-2025-66063—15.1%
——5——CVE-2025-11080—15.1%
——5——CVE-2026-33653—15.1%
——5——CVE-2023-22817—15.1%
——5——CVE-2022-48659—15.1%
——5——CVE-2025-49246—15.1%
——5——CVE-2026-33849—15.1%
——5——CVE-2025-62916—15.1%
——5——CVE-2025-13964—15.1%
——5——CVE-2021-47643—15.0%
——5——CVE-2026-27448—15.1%
——5——CVE-2026-34729—15.1%
——5——CVE-2022-49090—15.1%
——5——CVE-2026-33848—15.1%
——5——CVE-2024-580968.8 HIG15.1%
——5In the Linux kernel, the following vulnerability has been resolved:
wifi: ath11k: add srng->lock for ath11k_hal_srng_* in monitor mode
ath11k_hal_srng_* should be used with srng->lock to protect srng data.
For ath11k_dp_rx_mon_dest_process() and ath11k_dp_full_mon_process_rx(),
they use ath11k_hal_srng_* for many times but never call srng->lock.
So when running (full) monitor mode, warning will occur:
RIP: 0010:ath11k_hal_srng_dst_peek+0x18/0x30 [ath11k]
Call Trace:
? ath11k_hal_srng_dst_peek+0x18/0x30 [ath11k]
ath11k_dp_rx_process_mon_status+0xc45/0x1190 [ath11k]
? idr_alloc_u32+0x97/0xd0
ath11k_dp_rx_process_mon_rings+0x32a/0x550 [ath11k]
ath11k_dp_service_srng+0x289/0x5a0 [ath11k]
ath11k_pcic_ext_grp_napi_poll+0x30/0xd0 [ath11k]
__napi_poll+0x30/0x1f0
net_rx_action+0x198/0x320
__do_softirq+0xdd/0x319
So add srng->lock for them to avoid such warnings.
Inorder to fetch the srng->lock, should change srng's definition from
'void' to 'struct hal_srng'. And initialize them elsewhere to prevent
one line of code from being too long. This is consistent with other ring
process functions, such as ath11k_dp_process_rx().
Tested-on: WCN6855 hw2.0 PCI WLAN.HSP.1.1-03125-QCAHSPSWPL_V1_V2_SILICONZ_LITE-3.6510.30
Tested-on: QCN9074 hw1.0 PCI WLAN.HK.2.7.0.1-01744-QCAHKSWPL_SILICONZ-124dCVE-2026-9592—15.1%
——5SEPPmail Secure Email Gateway & SEPPmail Cloud before version 15.0.4.2 allows an attacker to replay & hijack a user session in the GINA web portal, as the session token is disclosed inside the URL and a HTTP header.41dCVE-2025-48150—15.1%
——5——CVE-2022-49083—15.0%
——5——CVE-2024-53070—15.1%
——5——CVE-2025-49293—15.1%
——5——CVE-2021-46953—15.1%
——5——CVE-2024-13582—15.1%
——5——CVE-2024-13751—15.1%
——5——CVE-2025-4369—15.1%
——5——CVE-2026-704298.1 HIG15.1%
——5Jenkins 2.575 and earlier, LTS 2.568.1 and earlier handles case-insensitivity in user names and group names inconsistently, allowing attackers able to create new users or groups with names that case-insensitively match other characters to impersonate other users or be granted their permissions in some circumstances.21dCVE-2021-469227.8 HIG15.1%
——5In the Linux kernel, the following vulnerability has been resolved:
KEYS: trusted: Fix TPM reservation for seal/unseal
The original patch 8c657a0590de ("KEYS: trusted: Reserve TPM for seal
and unseal operations") was correct on the mailing list:
https://lore.kernel.org/linux-integrity/20210128235621.127925-4-jarkko@kernel.org/
But somehow got rebased so that the tpm_try_get_ops() in
tpm2_seal_trusted() got lost. This causes an imbalanced put of the
TPM ops and causes oopses on TIS based hardware.
This fix puts back the lost tpm_try_get_ops()24dCVE-2024-531987.8 HIG15.1%
——5In the Linux kernel, the following vulnerability has been resolved:
xen: Fix the issue of resource not being properly released in xenbus_dev_probe()
This patch fixes an issue in the function xenbus_dev_probe(). In the
xenbus_dev_probe() function, within the if (err) branch at line 313, the
program incorrectly returns err directly without releasing the resources
allocated by err = drv->probe(dev, id). As the return value is non-zero,
the upper layers assume the processing logic has failed. However, the probe
operation was performed earlier without a corresponding remove operation.
Since the probe actually allocates resources, failing to perform the remove
operation could lead to problems.
To fix this issue, we followed the resource release logic of the
xenbus_dev_remove() function by adding a new block fail_remove before the
fail_put block. After entering the branch if (err) at line 313, the
function will use a goto statement to jump to the fail_remove block,
ensuring that the previously acquired resources are correctly released,
thus preventing the reference count leak.
This bug was identified by an experimental static analysis tool developed
by our team. The tool specializes in analyzing reference count operations
and detecting potential issues where resources are not properly managed.
In this case, the tool flagged the missing release operation as a
potential problem, which led to the development of this patch.24dCVE-2026-728017.5 HIG15.1%
——5SiYuan versions before v3.7.4 disclose encrypted-notebook key-derivation material and wrapped data keys through unauthenticated endpoints in publish mode. Attackers can retrieve Argon2id salt, cost parameters, password verifiers, and wrapped notebook keys to perform unlimited offline master-password cracking without rate limiting.1dCVE-2018-11264—15.1%
——5——CVE-2022-26356—15.1%
——5——CVE-2024-13588—15.1%
——5——CVE-2024-134616.4 MED15.1%
——5The Autoship Cloud for WooCommerce Subscription Products plugin for WordPress is vulnerable to Stored Cross-Site Scripting via the plugin's 'autoship-create-scheduled-order-action' shortcode in all versions up to, and including, 2.8.0 due to insufficient input sanitization and output escaping on user supplied attributes. This makes it possible for authenticated attackers, with contributor-level access and above, to inject arbitrary web scripts in pages that will execute whenever a user accesses an injected page.22dCVE-2025-53997—15.1%
——5——CVE-2024-31265—15.1%
——5——CVE-2023-41088—15.1%
——5——CVE-2021-469777.8 HIG15.1%
——5In the Linux kernel, the following vulnerability has been resolved:
KVM: VMX: Disable preemption when probing user return MSRs
Disable preemption when probing a user return MSR via RDSMR/WRMSR. If
the MSR holds a different value per logical CPU, the WRMSR could corrupt
the host's value if KVM is preempted between the RDMSR and WRMSR, and
then rescheduled on a different CPU.
Opportunistically land the helper in common x86, SVM will use the helper
in a future commit.24dCVE-2025-54596—15.1%
——5——CVE-2024-13315—15.1%
——5——CVE-2021-469937.8 HIG15.1%
——5In the Linux kernel, the following vulnerability has been resolved:
sched: Fix out-of-bound access in uclamp
Util-clamp places tasks in different buckets based on their clamp values
for performance reasons. However, the size of buckets is currently
computed using a rounding division, which can lead to an off-by-one
error in some configurations.
For instance, with 20 buckets, the bucket size will be 1024/20=51. A
task with a clamp of 1024 will be mapped to bucket id 1024/51=20. Sadly,
correct indexes are in range [0,19], hence leading to an out of bound
memory access.
Clamp the bucket id to fix the issue.24d