Vulnerabilidades explotables hoy
367,284en la vista actual
Score único combinando CVSS, membresía KEV y EPSS. Cada CVE con su ficha propia — timeline desde publicación hasta explotación activa.
En catálogo KEV1,685
Nuevos KEV · 24H0
Exploit Today ≥ 701,629
Distribución · última ventana
- Crítico2,295
- Alto9,356
- Medio5,355
- Bajo528
Ventana
Severidad
Filtros
CVECVSSEPSSKEVRExplotTítuloVis.
CVE-2021-25344—1.9%
——1——CVE-2025-60075—1.9%
——1——CVE-2025-58485—1.9%
——1——CVE-2022-25666—1.9%
——1——CVE-2025-55264—1.9%
——1——CVE-2025-669635.5 MED1.9%
——1An issue in Hitron HI3120 v.7.2.4.5.2b1 allows a local attacker to obtain sensitive information via the Logout option in the index.html58dCVE-2026-2889—1.9%
——1——CVE-2026-47272—1.9%
——1——CVE-2026-81406.5 MED1.9%
——1Concrete CMS 9.5.0 and below does not validate a CSRF token before processing requests to /dashboard/extend/install/download/<remoteId>. The download() method in concrete/controllers/single_page/dashboard/extend/install.php checks only the canInstallPackages() permission before fetching a remote marketplace package and writing it to the server's DIR_PACKAGES directory. Because the endpoint is a state-changing GET route with no token enforcement, an attacker who can cause an authenticated administrator to visit a crafted page can force an arbitrary marketplace package to be downloaded. In order to be vulnerable, the victim must be passing canInstallPackages() and the site must be connected to the Concrete marketplace. The Concrete CMS security team gave this vulnerability a CVSS v.4.0 score of 7.5 with vector CVSS:4.0/AV:N/AC:H/AT:P/PR:N/UI:A/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N. Thanks https://github.com/maru1009 for reporting.40dCVE-2026-41158—1.9%
——1——CVE-2026-23123—1.9%
——1——CVE-2025-48085—1.9%
——1——CVE-2025-14305—1.9%
——1——CVE-2026-3777—1.9%
——1——CVE-2022-33302—1.9%
——1——CVE-2025-71154—1.9%
——1——CVE-2025-43524—1.9%
——1——CVE-2025-71232—1.9%
——1——CVE-2025-71094—1.9%
——1——CVE-2023-53151—1.9%
——1——CVE-2025-48083—1.9%
——1——CVE-2021-0525—1.9%
——1——CVE-2022-20487—1.9%
——1——CVE-2026-43070—1.9%
——1——CVE-2025-39893—1.9%
——1——CVE-2025-71235—1.9%
——1——CVE-2024-47157—1.9%
——1——CVE-2022-20037—1.9%
——1——CVE-2025-62896—1.9%
——1——CVE-2026-43460—1.9%
——1——CVE-2026-530857.8 ALT1.9%
——1In the Linux kernel, the following vulnerability has been resolved:
bpf: fix mm lifecycle in open-coded task_vma iterator
The open-coded task_vma iterator reads task->mm locklessly and acquires
mmap_read_trylock() but never calls mmget(). If the task exits
concurrently, the mm_struct can be freed as it is not
SLAB_TYPESAFE_BY_RCU, resulting in a use-after-free.
Safely read task->mm with a trylock on alloc_lock and acquire an mm
reference. Drop the reference via bpf_iter_mmput_async() in _destroy()
and error paths. bpf_iter_mmput_async() is a local wrapper around
mmput_async() with a fallback to mmput() on !CONFIG_MMU.
Reject irqs-disabled contexts (including NMI) up front. Operations used
by _next() and _destroy() (mmap_read_unlock, bpf_iter_mmput_async)
take spinlocks with IRQs disabled (pool->lock, pi_lock). Running from
NMI or from a tracepoint that fires with those locks held could
deadlock.
A trylock on alloc_lock is used instead of the blocking task_lock()
(get_task_mm) to avoid a deadlock when a softirq BPF program iterates
a task that already holds its alloc_lock on the same CPU.40dCVE-2023-23431—1.9%
——1——CVE-2026-644207.0 ALT1.9%
——1In the Linux kernel, the following vulnerability has been resolved:
mfd: cros_ec: Delay dev_set_drvdata() until probe success
If ec_device_probe() fails, cros_ec_class_release releases memory for the
cros_ec_dev structure. However, because the drvdata was already set,
sub-drivers like cros_ec_typec can still retrieve the stale pointer via the
platform device. This leads to a use-after-free when cros_ec_typec attempts
to access &typec->ec->ec->dev on a device that has already been released.
Move dev_set_drvdata() to ensure that the pointer is only made available
once all initialization steps have succeeded.
sysfs: cannot create duplicate filename '/class/chromeos/cros_ec'
Call trace:
sysfs_do_create_link_sd+0x94/0xdc
sysfs_create_link+0x30/0x44
device_add_class_symlinks+0x90/0x13c
device_add+0xf0/0x50c
ec_device_probe+0x150/0x4f0
platform_probe+0xa0/0xe0
...
BUG: KASAN: invalid-access in __memcpy+0x44/0x230
Write at addr f5ffff809e2d33ac by task kworker/u32:5/125
Pointer tag: [f5], memory tag: [fe]
Tainted : [W]=WARN, [O]=OOT_MODULE
Hardware name: Google Navi unprovisioned 0x7FFFFFFF/sku0 board/sku3
Workqueue: events_unbound deferred_probe_work_func
Call trace:
__memcpy+0x44/0x230
cros_ec_check_features+0x60/0xcc [cros_ec_proto]
cros_typec_probe+0xe8/0x6e0 [cros_ec_typec]
platform_probe+0xa0/0xe015dCVE-2026-44309—1.9%
——1——CVE-2026-645887.8 ALT1.9%
——1In the Linux kernel, the following vulnerability has been resolved:
fuse-uring: fix data races on ring->ready
On weakly-ordered architectures, the store to fiq->ops can be
reordered past the store to ring->ready, allowing a CPU that sees
ring->ready == true via fuse_uring_ready() to dispatch requests
through a stale fiq->ops pointer. Upgrade the store to
smp_store_release() and the load in fuse_uring_ready() to
smp_load_acquire() so that the preceding WRITE_ONCE(fiq->ops, ...)
is visible to any CPU that observes ring->ready == true.
Additionally, fuse_uring_do_register() publishes ring->ready with
WRITE_ONCE() but the fast-path check reads it with a plain load.
This is a marked-vs-unmarked access that KCSAN will flag. Wrap it in
READ_ONCE() to mark it without adding unnecessary ordering.
Also wrap the fc->ring load in fuse_uring_ready() in READ_ONCE() to
prevent the compiler from reloading it between the NULL check and the
dereference.15dCVE-2025-31983—1.9%
——1——CVE-2026-530677.8 ALT1.9%
——1In the Linux kernel, the following vulnerability has been resolved:
PCI: endpoint: pci-ep-msi: Fix error unwind and prevent double alloc
pci_epf_alloc_doorbell() stores the allocated doorbell message array in
epf->db_msg/epf->num_db before requesting MSI vectors. If MSI allocation
fails, the array is freed but the EPF state may still point to freed
memory.
Clear epf->db_msg and epf->num_db on the MSI allocation failure path so
that later cleanup cannot double-free the array and callers can retry
allocation.
Also return -EBUSY when doorbells have already been allocated to prevent
leaking or overwriting an existing allocation.42dCVE-2026-46226—1.9%
——1——CVE-2026-712598.6 ALT1.9%
——1ESPHome through 2026.7.0-dev contains an operator-precedence bug in the cv.url validator in esphome/config_validation.py. Because binds tighter than , any file: URI passes validation regardless of netloc. This validator gates the field of the external_components YAML directive's git source schema, which is passed to (git supports file:// natively).6dCVE-2025-71084—1.9%
——1——