Vulnerabilities exploitable today
358,955in 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,665
New KEV · 24H0
Exploit Today ≥ 701,607
Distribution · last window
- Critical2,697
- High11,575
- Medium7,294
- Low679
Window
Severity
Flags
CVECVSSEPSSKEVRExploitTitleMod.
CVE-2026-39332—10.5%
——3——CVE-2021-26384—10.5%
——3——CVE-2026-1042—10.5%
——3——CVE-2023-42896—10.5%
——3——CVE-2026-102343.5 LOW10.5%
——3A vulnerability was detected in Mettle sendportal up to 3.0.1. This affects an unknown part of the file /webview/ of the component Campaign Handler. The manipulation of the argument content results in cross site scripting. The attack can be launched remotely. The exploit is now public and may be used. The project was informed of the problem early through an issue report but has not responded yet.22dCVE-2020-7567—10.5%
——3——CVE-2016-3850—10.5%
——3——CVE-2025-57897—10.5%
——3——CVE-2024-36458—10.5%
——3——CVE-2022-39087—10.5%
——3——CVE-2022-21152—10.5%
——3——CVE-2026-24991—10.5%
——3——CVE-2025-220157.8 HIG10.5%
——3In the Linux kernel, the following vulnerability has been resolved:
mm/migrate: fix shmem xarray update during migration
A shmem folio can be either in page cache or in swap cache, but not at the
same time. Namely, once it is in swap cache, folio->mapping should be
NULL, and the folio is no longer in a shmem mapping.
In __folio_migrate_mapping(), to determine the number of xarray entries to
update, folio_test_swapbacked() is used, but that conflates shmem in page
cache case and shmem in swap cache case. It leads to xarray multi-index
entry corruption, since it turns a sibling entry to a normal entry during
xas_store() (see [1] for a userspace reproduction). Fix it by only using
folio_test_swapcache() to determine whether xarray is storing swap cache
entries or not to choose the right number of xarray entries to update.
[1] https://lore.kernel.org/linux-mm/Z8idPCkaJW1IChjT@casper.infradead.org/
Note:
In __split_huge_page(), folio_test_anon() && folio_test_swapcache() is
used to get swap_cache address space, but that ignores the shmem folio in
swap cache case. It could lead to NULL pointer dereferencing when a
in-swap-cache shmem folio is split at __xa_store(), since
!folio_test_anon() is true and folio->mapping is NULL. But fortunately,
its caller split_huge_page_to_list_to_order() bails out early with EBUSY
when folio->mapping is NULL. So no need to take care of it here.14dCVE-2025-32962—10.5%
——3——CVE-2025-60794—10.5%
——3——CVE-2022-39081—10.5%
——3——CVE-2026-5170—10.5%
——3——CVE-2025-7977—10.5%
——3——CVE-2025-63041—10.5%
——3——CVE-2026-15311—10.5%
——3——CVE-2026-25221—10.5%
——3——CVE-2026-47749—10.5%
——3——CVE-2026-112657.5 HIG10.5%
——3Inappropriate implementation in Autofill in Google Chrome prior to 149.0.7827.53 allowed a remote attacker to leak cross-origin data via a crafted HTML page. (Chromium security severity: Low)21dCVE-2020-37054—10.5%
——3——CVE-2025-2870—10.5%
——3——CVE-2023-35192—10.5%
——3——CVE-2025-43367—10.5%
——3——CVE-2022-36348—10.5%
——3——CVE-2019-2228—10.5%
——3——CVE-2022-21140—10.5%
——3——CVE-2022-49917—10.5%
——3——CVE-2023-34430—10.5%
——3——CVE-2025-47789—10.5%
——3——CVE-2022-37025—10.5%
——3——CVE-2026-2121—10.5%
——3——CVE-2026-725447.5 HIG10.5%
——3An integrity verification vulnerability in OpenSignLabs OpenSign through 2.37.0 allows unauthenticated remote attackers to forge document audit-trail entries via the triggerevent Parse cloud function. The function accepts viewer identity and IP address as caller-supplied parameters without authentication, allowing fabrication of arbitrary audit log entries. An attacker can tamper with the legal audit trail of any signed document, undermining non-repudiation.2dCVE-2025-7663—10.5%
——3——CVE-2024-476797.8 HIG10.5%
——3In the Linux kernel, the following vulnerability has been resolved:
vfs: fix race between evice_inodes() and find_inode()&iput()
Hi, all
Recently I noticed a bug[1] in btrfs, after digged it into
and I believe it'a race in vfs.
Let's assume there's a inode (ie ino 261) with i_count 1 is
called by iput(), and there's a concurrent thread calling
generic_shutdown_super().
cpu0: cpu1:
iput() // i_count is 1
->spin_lock(inode)
->dec i_count to 0
->iput_final() generic_shutdown_super()
->__inode_add_lru() ->evict_inodes()
// cause some reason[2] ->if (atomic_read(inode->i_count)) continue;
// return before // inode 261 passed the above check
// list_lru_add_obj() // and then schedule out
->spin_unlock()
// note here: the inode 261
// was still at sb list and hash list,
// and I_FREEING|I_WILL_FREE was not been set
btrfs_iget()
// after some function calls
->find_inode()
// found the above inode 261
->spin_lock(inode)
// check I_FREEING|I_WILL_FREE
// and passed
->__iget()
->spin_unlock(inode) // schedule back
->spin_lock(inode)
// check (I_NEW|I_FREEING|I_WILL_FREE) flags,
// passed and set I_FREEING
iput() ->spin_unlock(inode)
->spin_lock(inode) ->evict()
// dec i_count to 0
->iput_final()
->spin_unlock()
->evict()
Now, we have two threads simultaneously evicting
the same inode, which may trigger the BUG(inode->i_state & I_CLEAR)
statement both within clear_inode() and iput().
To fix the bug, recheck the inode->i_count after holding i_lock.
Because in the most scenarios, the first check is valid, and
the overhead of spin_lock() can be reduced.
If there is any misunderstanding, please let me know, thanks.
[1]: https://lore.kernel.org/linux-btrfs/000000000000eabe1d0619c48986@google.com/
[2]: The reason might be 1. SB_ACTIVE was removed or 2. mapping_shrinkable()
return false when I reproduced the bug.9dCVE-2026-56023—10.5%
——3——CVE-2025-15221—10.5%
——3——