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,687
Nuevos KEV · 24H0
Exploit Today ≥ 701,629
Distribución · última ventana
- Crítico2,311
- Alto9,414
- Medio5,381
- Bajo529
Ventana
Severidad
Filtros
CVECVSSEPSSKEVRExplotTítuloVis.
CVE-2019-25345—2.7%
——1——CVE-2025-39768—2.7%
——1——CVE-2024-33052—2.7%
——1——CVE-2026-632808.8 ALT2.7%
——1Joomla Extension - regularlabs.com - Inconsistent CSRF token checks / privilege checks in Regular Labs conditions manager - Conditions administration did not consistently enforce tokens and component/mapped-item permissions.36dCVE-2025-39771—2.7%
——1——CVE-2025-39887—2.7%
——1——CVE-2026-640587.8 ALT2.7%
——1In the Linux kernel, the following vulnerability has been resolved:
netfs: Fix netfs_read_folio() to wait on writeback
Fix netfs_read_folio() to wait for an ongoing writeback to complete so that
it can trust the dirty flag and whatever is attached to folio->private
(folio->private may get cleaned up by the collector before it clears the
writeback flag).33dCVE-2025-39856—2.7%
——1——CVE-2025-71108—2.7%
——1——CVE-2021-0398—2.7%
——1——CVE-2026-746407.8 ALT2.7%
——1In the Linux kernel, the following vulnerability has been resolved:
ALSA: FCP: fix OOB write in fcp_meter_ctl_get()
fcp_ioctl_set_meter_map() bounds the user-supplied Level Meter map size
by the driver's own limit of 255
if (map.map_size < 1 || map.map_size > 255 ||
map.meter_slots < 1 || map.meter_slots > 255)
return -EINVAL;
and passes it to fcp_add_new_ctl() as the control's channel count, where
it is stored as elem->channels.
Every control read writes into struct snd_ctl_elem_value, whose integer
array is declared long value[128], so the limit is 128, not 255.
fcp_meter_ctl_get() stores one 64-bit word per channel into that array
with no bound of its own:
for (i = 0; i < elem->channels; i++) {
int idx = private->meter_level_map[i];
int value = idx < 0 ? 0 : le32_to_cpu(resp[idx]);
ucontrol->value.integer.value[i] = value;
}
snd_ctl_elem_read_user() serves that object from
memdup_user(_control, sizeof(*control)), 1224 bytes on LP64 out of
kmalloc-2048. offsetof(struct snd_ctl_elem_value, value) is 72, so
element i is written at byte 72 + 8 * i and element 144 already lands
past the allocation. At map_size 255 the last store ends at byte 2112,
888 bytes past the object and 64 bytes into the adjacent slab object.
The stored words come from the device and meter_level_map[] selects
which word lands in which slot, so extent and contents are both
controlled.
The core does not catch this. snd_ctl_check_elem_info() is reached only
from __snd_ctl_elem_info(), which snd_ctl_elem_read() calls under
CONFIG_SND_CTL_DEBUG; without that option snd_ctl_skip_validation() is a
compile-time true. __snd_ctl_add_replace() validates kcontrol->count and
never inspects elem->channels.
Installing an oversized map needs CAP_SYS_RAWIO, but the control outlives
the hwdep descriptor that created it, so the out-of-bounds stores are
issued by any process able to read controls on /dev/snd/controlC0.
KASAN on 7.2.0-rc5 (arm64), triggered by an unprivileged control read:
BUG: KASAN: slab-out-of-bounds in fcp_meter_ctl_get
Write of size 8 at addr ffff000017af04c8 by task fcp_trigger/185
__asan_store8
fcp_meter_ctl_get
snd_ctl_elem_read
snd_ctl_ioctl
Allocated by task 185:
memdup_user
snd_ctl_ioctl
The buggy address is located 0 bytes to the right of
allocated 1224-byte region [ffff000017af0000, ffff000017af04c8)
Bound the map size by the ABI limit rather than by 255, and bound the
store loop at the sink so it cannot run past the value array whatever
elem->channels holds.
Discovered by XBOW, triaged by Baul Lee <baul.lee@xbow.com>8dCVE-2026-234297.8 ALT2.7%
——1In the Linux kernel, the following vulnerability has been resolved:
iommu/sva: Fix crash in iommu_sva_unbind_device()
domain->mm->iommu_mm can be freed by iommu_domain_free():
iommu_domain_free()
mmdrop()
__mmdrop()
mm_pasid_drop()
After iommu_domain_free() returns, accessing domain->mm->iommu_mm may
dereference a freed mm structure, leading to a crash.
Fix this by moving the code that accesses domain->mm->iommu_mm to before
the call to iommu_domain_free().39dCVE-2026-648768.8 ALT2.7%
——1Joomla Extension - regularlabs.com - Inconsistent CSRF token checks / privilege checks in GeoIP extension - Database-update requests lacked consistent token and Super User checks, this could cause unauthorized updates.35dCVE-2025-71105—2.7%
——1——CVE-2026-83674.8 MED2.7%
——1aria2c accepts a server certificate with incorrect Extended Key Usage (EKU). If the attackers compromise a certificate (with the associated private key) issued for a different purpose, they may be able to reuse it for TLS server authentication.13dCVE-2025-39777—2.7%
——1——CVE-2026-168747.8 ALT2.7%
——1IBM AIX 7.2, and 7.3 and IBM PowerVM VIOS 4.1 could allow a local attacker to obtain root privileges due to improper enforcement of RBAC authentication roles.12dCVE-2026-746277.8 ALT2.7%
——1In the Linux kernel, the following vulnerability has been resolved:
net: devmem: prevent net-iov / page mixing
We should either have net_iov or page backed frags in a single skb,
otherwise it blows up down the stack. Don't allow mixing in
zerocopy_fill_skb_from_devmem().8dCVE-2025-20105—2.7%
——1——CVE-2023-50442—2.7%
——1——CVE-2023-53303—2.7%
——1——CVE-2025-38509—2.7%
——1——CVE-2026-31493—2.7%
——1——CVE-2025-38518—2.7%
——1——CVE-2026-636848.8 ALT2.7%
——1Joomla Extension - regularlabs.com - Inconsistent CSRF token checks / privilege checks in various admin/import/export actions of multiple Regular Labs extension - Administrator actions, editor popups and import/export requests lacked consistent token, item-permission and input-validation checks. Unauthorized backend users or CSRF attacks could expose, create or modify extension configuration and items.36dCVE-2026-31742—2.7%
——1——CVE-2026-28281—2.7%
——1——CVE-2019-20779—2.7%
——1——CVE-2026-684587.8 ALT2.7%
——1In the Linux kernel, the following vulnerability has been resolved:
binder: cache secctx size before release zeroes it
binder_transaction() bounds the scatter-gather buffer area with
sg_buf_end_offset and subtracts the aligned LSM context size because
the secctx is written at the tail of that area. The subtraction reads
lsmctx.len, but that field has already been cleared by the time the
line runs:
security_secid_to_secctx(secid, &lsmctx) /* lsmctx.len set */
lsmctx_aligned_size = ALIGN(lsmctx.len, sizeof(u64))
extra_buffers_size += lsmctx_aligned_size
...
security_release_secctx(&lsmctx) /* memset zeroes len */
...
sg_buf_end_offset = sg_buf_offset + extra_buffers_size
- ALIGN(lsmctx.len, sizeof(u64)) /* ALIGN(0,8) */
security_release_secctx() does memset(cp, 0, sizeof(*cp)), so lsmctx.len
reads back as 0 and the subtraction contributes nothing, leaving
sg_buf_end_offset too large by the aligned secctx size on every
transaction to a txn_security_ctx node.
Each BINDER_TYPE_PTR object then derives buf_left = sg_buf_end_offset -
sg_buf_offset as the sole upper bound on its copy, so the inflated end
offset lets the copy run into the bytes that already hold the secctx.
The aligned size must therefore be cached before release rather than
re-read from the now-cleared field. Fix by caching it in
lsmctx_aligned_size at function scope when it is first computed and
subtracting lsmctx_aligned_size instead of re-reading lsmctx.len after
release. Reuse the same value for the earlier buf_offset computation.16dCVE-2026-743257.8 ALT2.7%
——1In the Linux kernel, the following vulnerability has been resolved:
wifi: mt76: use kfree_rcu for offchannel link in mt76_put_vif_phy_link
mt76_put_vif_phy_link() frees the offchannel mlink with plain kfree()
after rcu_assign_pointer(NULL). However, rcu_assign_pointer only prevents
future RCU readers from obtaining the pointer -- it does not wait for
existing readers that already hold it via rcu_dereference.
The TX datapath (e.g. mt7996_mac_write_txwi) dereferences mlink->wcid
and mlink->idx under rcu_read_lock. If a TX softirq obtained the pointer
via rcu_dereference just before the NULL assignment, it will dereference
freed memory after the kfree.
struct mt76_vif_link already contains an rcu_head field that is unused at
this free site -- a developer oversight, since the adjacent
kfree_rcu_mightsleep call for rx_sc in the same function shows the
pattern was understood.
Replace kfree(mlink) with kfree_rcu(mlink, rcu_head).16dCVE-2026-640317.8 ALT2.7%
——1In the Linux kernel, the following vulnerability has been resolved:
erofs: fix managed cache race for unaligned extents
After unaligned compressed extents were introduced, the following race
could occur:
[Thread 1] [Thread 2]
(z_erofs_fill_bio_vec)
<handle a Z_EROFS_PREALLOCATED_FOLIO folio>
...
filemap_add_folio (1)
(z_erofs_bind_cache)
<the same folio is found..>
..
..
folio_attach_private (2)
filemap_add_folio (3) again
Since (1) is executed but (2) hasn't been executed yet, it's possible
that another thread finds the same managed folio in z_erofs_bind_cache()
for a different pcluster and calls filemap_add_folio() again since
folio->private is still Z_EROFS_PREALLOCATED_FOLIO.
Fix this by explicitly clearing folio->private before making the folio
visible in the managed cache so that another pcluster can simply wait
on the locked managed folio as what we did for other shared cases [1].
This only impacts unaligned data compression (`-E48bit` with zstd,
for example).
[1] Commit 9e2f9d34dd12 ("erofs: handle overlapped pclusters out of
crafted images properly") was originally introduced to handle crafted
overlapped extents, but it addresses unaligned extents as well.33dCVE-2026-743447.8 ALT2.7%
——1In the Linux kernel, the following vulnerability has been resolved:
bpf: Clear rb node linkage when freeing bpf_rb_root
bpf_rb_root_free() detaches the root by copying the current rb_root_cached
and then replacing the live root with RB_ROOT_CACHED. It then walks the
copied root and drops each object contained in the tree.
This leaves the rb node state intact while dropping the object. If the
object is refcounted and survives the drop, its bpf_rb_node_kern still
contains an owner pointer to the freed root and stale rb tree linkage. If
a later bpf_rb_root allocation reuses the same address, bpf_rbtree_remove()
can incorrectly pass the owner check and call rb_erase_cached() on a node
whose rb pointers belong to the old tree.
Mirror the list draining behavior by marking nodes as busy while the root
is being detached, then clear the rb node and release the owner before
dropping the containing object. This makes surviving nodes unowned and
safe to reject from remove or accept for a later add.16dCVE-2026-683207.3 ALT2.7%
——1In the Linux kernel, the following vulnerability has been resolved:
sctp: fix auth_chunk_list capacity check in sctp_auth_ep_add_chunkid
sctp_auth_ep_add_chunkid() uses SCTP_NUM_CHUNK_TYPES (20) as the
capacity limit for ep->auth_chunk_list, allowing it to hold up to
20 chunk entries (param_hdr.length up to 24). However, the copy
destination asoc->c.auth_chunks in struct sctp_cookie is only
SCTP_AUTH_MAX_CHUNKS (16) entries (20 bytes). When more than 16
chunks are added, sctp_association_init() memcpy overflows the
destination by up to 4 bytes.
Fix by using SCTP_AUTH_MAX_CHUNKS as the capacity limit, matching
the destination capacity.13dCVE-2026-747537.8 ALT2.6%
——1In the Linux kernel, the following vulnerability has been resolved:
perf: Reject exited events as group leaders
perf_event_remove_on_exec() sets remove-on-exec events to the EXIT state
and detaches their group relationships. The event's file descriptor can
remain open, however, and perf_event_open() currently accepts that event
as a group leader because its early validation rejects only REVOKED and
DEAD events.
A new sibling can consequently be linked to the detached leader. When
the leader is closed, perf_group_detach() observes that its
PERF_ATTACH_GROUP bit is already clear and skips the new sibling. The
sibling then retains a group_leader pointer to the freed event.
Reject group leaders in the EXIT state. Perform the check while holding
the shared context mutex so that an exec in the target task cannot detach
the leader between validation and group attachment.
[peterz: make the earlier test fully consistent]6dCVE-2026-533687.1 ALT2.7%
——1In the Linux kernel, the following vulnerability has been resolved:
f2fs: fix fsck inconsistency caused by incorrect nat_entry flag usage
f2fs_need_dentry_mark() reads nat_entry flags without mutual exclusion
with the checkpoint path, which can result in an incorrect inode block
marking state. The scenario is as follows:
create & write & fsync 'file A' write checkpoint
- f2fs_do_sync_file // inline inode
- f2fs_write_inode // inode folio is dirty
- f2fs_write_checkpoint
- f2fs_flush_merged_writes
- f2fs_sync_node_pages
- f2fs_fsync_node_pages // no dirty node
- f2fs_need_inode_block_update // return true
- f2fs_fsync_node_pages // inode dirtied
- f2fs_need_dentry_mark //return true
- f2fs_flush_nat_entries
- f2fs_write_checkpoint end
- __write_node_folio // inode with DENT_BIT_SHIFT set
SPO, "fsck --dry-run" find inode has already checkpointed but still
with DENT_BIT_SHIFT set
The state observed by f2fs_need_dentry_mark() can differ from the state
observed in __write_node_folio() after acquiring sbi->node_write. The
root cause is that the semantics of IS_CHECKPOINTED and
HAS_FSYNCED_INODE are only guaranteed after the checkpoint write has
fully completed.
This patch moves set_dentry_mark() into __write_node_folio() and
protects it with the sbi->node_write lock.34dCVE-2026-631196.2 MED2.7%
——1MCP Ruby SDK is the official Ruby SDK for Model Context Protocol servers and clients. Prior to 0.23.0, MCP::Server::Transports::StdioTransport and MCP::Client::Stdio in the mcp gem use IO#gets without a byte limit, allowing a peer that sends data without a newline to exhaust process memory. This issue is fixed in version 0.23.0.33dCVE-2026-533567.8 ALT2.6%
——1In the Linux kernel, the following vulnerability has been resolved:
drm/i915/gem: Fix phys BO pread/pwrite with offset
sg_page() returns struct page pointer not (void *) so the scaling
of pread/pwrite is wrong for phys BO and wrong parts of BO would be
accessed if non-zero offset is used.
Last impacted platform with overlay or cursor planes using phys
mapping was Gen3/945G/Lakeport.
(cherry picked from commit 3e49a2f85070b2fb672c1e0fdba281a4ea3aebe6)41dCVE-2026-638147.8 ALT2.6%
——1In the Linux kernel, the following vulnerability has been resolved:
f2fs: validate ACL entry sizes in f2fs_acl_from_disk()
f2fs_acl_count() only validates the aggregate ACL xattr length. A
malformed ACL can still place ACL_USER or ACL_GROUP in a slot that only
contains struct f2fs_acl_entry_short bytes, and f2fs_acl_from_disk()
then reads entry->e_id before verifying that a full entry fits.
Require a short entry before reading e_tag and e_perm, and require a
full entry before reading e_id for ACL_USER and ACL_GROUP. Return
-EFSCORRUPTED from these new truncated-entry checks, while keeping the
pre-existing -EINVAL paths unchanged.
Validation reproduced this kernel report:
KASAN slab-out-of-bounds in __f2fs_get_acl+0x6fb/0x7e0
RIP: 0033:0x7f4b835ea7aa
The buggy address belongs to the object at ffff888114589960 which belongs
to the cache kmalloc-8 of size 8
The buggy address is located 0 bytes to the right of allocated 8-byte
region [ffff888114589960, ffff888114589968)
Read of size 4
Call trace:
dump_stack_lvl+0x66/0xa0 (?:?)
print_report+0xce/0x630 (?:?)
__f2fs_get_acl+0x6fb/0x7e0 (fs/f2fs/acl.c:169)
srso_alias_return_thunk+0x5/0xfbef5 (?:?)
__virt_addr_valid+0x224/0x430 (?:?)
kasan_report+0xe0/0x110 (?:?)
__f2fs_get_acl+0x5/0x7e0 (fs/f2fs/acl.c:169)
__get_acl+0x281/0x380 (?:?)
vfs_get_acl+0x10b/0x190 (?:?)
do_get_acl+0x2a/0x410 (?:?)
do_get_acl+0x9/0x410 (?:?)
do_getxattr+0xe8/0x260 (?:?)
filename_getxattr+0xd1/0x140 (?:?)
do_getname+0x2d/0x2d0 (?:?)
path_getxattrat+0x16c/0x200 (?:?)
lock_release+0xc8/0x290 (?:?)
cgroup_update_frozen+0x9d/0x320 (?:?)
lockdep_hardirqs_on_prepare+0xea/0x1a0 (?:?)
trace_hardirqs_on+0x1a/0x170 (?:?)
_raw_spin_unlock_irq+0x28/0x50 (?:?)
do_syscall_64+0x115/0x6a0 (arch/x86/entry/syscall_64.c:87)
entry_SYSCALL_64_after_hwframe+0x77/0x7f (?:?)16dCVE-2025-58261—2.6%
——1——CVE-2026-555866.6 MED2.6%
——1SumatraPDF is a multi-format reader for Windows. In 3.6.1 and earlier, a crafted CHM file can supply malformed LZX Huffman code lengths to make_decode_table in ext/CHMLib/lzx.c. In the long-code branch, the function writes new internal nodes through next_symbol before validating that the canonical Huffman table has overflowed. The PRETREE case can write beyond the 104-entry PRETREE_table into adjacent heap state in struct LZXstate when reached through chm_open, chm_retrieve_object, LZXdecompress, and BUILD_TABLE. This produces heap memory corruption in the parser process, while arbitrary code execution has not been demonstrated. No fixed version is available as of this review.11d