Vulnerabilities exploitable today
354,825in 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,656
New KEV · 24H0
Exploit Today ≥ 701,601
Distribution · last window
- Critical2,569
- High9,189
- Medium7,426
- Low693
Window
Severity
Flags
CVECVSSEPSSKEVRExploitTitleMod.
CVE-2025-38516—5.7%
——2——CVE-2026-45964—5.7%
——2——CVE-2026-28870—5.7%
——2——CVE-2025-380627.8 HIG5.7%
——2In the Linux kernel, the following vulnerability has been resolved:
genirq/msi: Store the IOMMU IOVA directly in msi_desc instead of iommu_cookie
The IOMMU translation for MSI message addresses has been a 2-step process,
separated in time:
1) iommu_dma_prepare_msi(): A cookie pointer containing the IOVA address
is stored in the MSI descriptor when an MSI interrupt is allocated.
2) iommu_dma_compose_msi_msg(): this cookie pointer is used to compute a
translated message address.
This has an inherent lifetime problem for the pointer stored in the cookie
that must remain valid between the two steps. However, there is no locking
at the irq layer that helps protect the lifetime. Today, this works under
the assumption that the iommu domain is not changed while MSI interrupts
being programmed. This is true for normal DMA API users within the kernel,
as the iommu domain is attached before the driver is probed and cannot be
changed while a driver is attached.
Classic VFIO type1 also prevented changing the iommu domain while VFIO was
running as it does not support changing the "container" after starting up.
However, iommufd has improved this so that the iommu domain can be changed
during VFIO operation. This potentially allows userspace to directly race
VFIO_DEVICE_ATTACH_IOMMUFD_PT (which calls iommu_attach_group()) and
VFIO_DEVICE_SET_IRQS (which calls into iommu_dma_compose_msi_msg()).
This potentially causes both the cookie pointer and the unlocked call to
iommu_get_domain_for_dev() on the MSI translation path to become UAFs.
Fix the MSI cookie UAF by removing the cookie pointer. The translated IOVA
address is already known during iommu_dma_prepare_msi() and cannot change.
Thus, it can simply be stored as an integer in the MSI descriptor.
The other UAF related to iommu_get_domain_for_dev() will be addressed in
patch "iommu: Make iommu_dma_prepare_msi() into a generic operation" by
using the IOMMU group mutex.3dCVE-2026-6329—5.7%
——2——CVE-2024-47969—5.7%
——2——CVE-2020-36992—5.7%
——2——CVE-2024-47022—5.7%
——2——CVE-2023-42832—5.7%
——2——CVE-2026-642987.1 HIG5.7%
——2In the Linux kernel, the following vulnerability has been resolved:
NFSv4: include MAY_WRITE in open permission mask for O_TRUNC
POSIX requires write permission to truncate a file, so an open() that
specifies O_TRUNC must be authorized for write access regardless of the
O_ACCMODE access mode.
nfs_open_permission_mask() builds the access mask passed to
nfs_may_open(), which is the local authorization gate for OPENs the
client serves itself from a cached write delegation via the
can_open_delegated() path in nfs4_try_open_cached(). The mask is
derived from O_ACCMODE alone, so an open(O_RDONLY | O_TRUNC) against a
file the caller cannot write requests only MAY_READ and passes the
local check. The OPEN is then satisfied locally and the truncation is
issued to the server as a SETATTR(size=0) over the delegation stateid,
which the server accepts under standard write-delegation semantics.
POSIX requires that this open fail with EACCES.
Include MAY_WRITE in the mask whenever O_TRUNC is set so the local
check matches the access the server would have enforced.2dCVE-2020-0024—5.7%
——2——CVE-2020-0336—5.7%
——2——CVE-2026-27691—5.7%
——2——CVE-2025-26859—5.7%
——2——CVE-2025-39808—5.7%
——2——CVE-2024-44210—5.7%
——2——CVE-2024-5166—5.7%
——2——CVE-2025-39676—5.7%
——2——CVE-2023-20601—5.7%
——2——CVE-2026-6870—5.7%
——2——CVE-2022-26124—5.7%
——2——CVE-2024-47154—5.7%
——2——CVE-2020-36989—5.7%
——2——CVE-2024-42013—5.7%
——2——CVE-2026-2602—5.7%
——2——CVE-2025-45768—5.7%
——2——CVE-2025-46288—5.7%
——2——CVE-2025-13225—5.7%
——2——CVE-2025-27233—5.7%
——2——CVE-2026-443937.4 HIG5.7%
——2An issue was discovered in OpenStack oslo.messaging 1.0.0 through 17.3.0. The oslo.messaging RabbitMQ driver does not perform TLS hostname verification when connecting to the message broker. When ssl_ca_file is configured, the driver enables certificate chain validation but does not pass the expected broker hostname into the underlying TLS stack. Any certificate signed by the deployment CA is accepted regardless of hostname, allowing an attacker who can intercept control-plane traffic to impersonate the RabbitMQ broker and perform a man-in-the-middle attack on RPC and notification traffic. All OpenStack services using oslo.messaging with RabbitMQ over TLS are affected.10dCVE-2025-28986—5.7%
——2——CVE-2026-148964.2 MED5.7%
——2HashiCorp Nomad and Nomad Enterprise are vulnerable to a cross-namespace authorization bypass in the dynamic host volumes feature that may allow an operator holding the host volume delete permission in one namespace to delete a sticky volume claim belonging to a job in another namespace. This vulnerability, CVE-2026-14896, is fixed in Nomad Community Edition 2.0.4 and Nomad Enterprise 2.0.4, 1.11.8, and 1.10.14.23dCVE-2025-5967—5.7%
——2——CVE-2025-0504—5.7%
——2——CVE-2026-639528.4 HIG5.7%
——2In the Linux kernel, the following vulnerability has been resolved:
memfd: deny writeable mappings when implying SEAL_WRITE
When SEAL_EXEC is added, SEAL_WRITE is implied to make W^X. But the
implied seal is set after the check that makes sure the memfd can not have
any writable mappings. This means one can use SEAL_EXEC to apply
SEAL_WRITE while having writeable mappings.
This breaks the contract that SEAL_WRITE provides and can be used by an
attacker to pass a memfd that appears to be write sealed but can still be
modified arbitrarily.
Fix this by adding the implied seals before the call for
mapping_deny_writable() is done.5dCVE-2025-24481—5.7%
——2——CVE-2025-9036—5.7%
——2——CVE-2022-34388—5.7%
——2——CVE-2020-36984—5.7%
——2——CVE-2022-50159—5.7%
——2——