Vulnerabilidades explotables hoy
406,817en 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,766
Nuevos KEV · 24H0
Exploit Today ≥ 701,698
Distribución · última ventana
- Crítico5,592
- Alto21,789
- Medio20,310
- Bajo2,113
Filtros
Ventana
Severidad
Filtros
CVECVSSEPSSKEVRExplotTítuloVis.
CVE-2026-907213.4 BAJ1.8%
——1Dell PowerProtect Data Domain, Feature Release versions 7.7.1.0 through 8.8, LTS2024 release versions 7.13.1.0 through 7.13.1.80, LTS2025 release versions 8.3.1.0 through 8.3.1.40, LTS2026 release versions 8.6.1.0 through 8.6.1.20, contain a Path Traversal vulnerability. A high privileged attacker with local access could potentially exploit this vulnerability, leading to Denial of service.5dCVE-2025-331775.5 MED1.8%
——1NVIDIA Jetson Linux and IGX OS contain a vulnerability in NvMap, where improper tracking of memory allocations could allow a local attacker to cause memory overallocation. A successful exploitation of this vulnerability might lead to denial of service.16dCVE-2026-529415.5 MED1.7%
——1In the Linux kernel, the following vulnerability has been resolved:
net/smc: avoid NULL deref of conn->lnk in smc_msg_event tracepoint
The smc_msg_event tracepoint class, shared by smc_tx_sendmsg and
smc_rx_recvmsg, unconditionally dereferences smc->conn.lnk:
__string(name, smc->conn.lnk->ibname)
conn->lnk is only set for SMC-R; for SMC-D it is NULL. Other code on
these paths already handles this (e.g. !conn->lnk in
SMC_STAT_RMB_TX_SIZE_SMALL()). With the tracepoint enabled, the first
sendmsg()/recvmsg() on an SMC-D socket crashes:
Oops: general protection fault, probably for non-canonical address
KASAN: null-ptr-deref in range [...]
RIP: 0010:strlen+0x1e/0xa0
Call Trace:
trace_event_raw_event_smc_msg_event (net/smc/smc_tracepoint.h:44)
smc_rx_recvmsg (net/smc/smc_rx.c:515)
smc_recvmsg (net/smc/af_smc.c:2859)
__sys_recvfrom (net/socket.c:2315)
__x64_sys_recvfrom (net/socket.c:2326)
do_syscall_64
The faulting address 0x3e0 is offsetof(struct smc_link, ibname),
confirming the NULL ->lnk deref. Enabling the tracepoint requires
root, but the trigger itself is unprivileged: socket(AF_SMC, ...) has
no capability check, and SMC-D negotiation needs no admin step on
s390 or on x86 with the loopback ISM device loaded.
Log an empty device name for SMC-D instead of dereferencing NULL.118dCVE-2026-43481—1.7%
——1——CVE-2022-20196—1.7%
——1——CVE-2026-43070—1.7%
——1——CVE-2026-234265.5 MED1.7%
——1In the Linux kernel, the following vulnerability has been resolved:
drm/logicvc: Fix device node reference leak in logicvc_drm_config_parse()
The logicvc_drm_config_parse() function calls of_get_child_by_name() to
find the "layers" node but fails to release the reference, leading to a
device node reference leak.
Fix this by using the __free(device_node) cleanup attribute to automatic
release the reference when the variable goes out of scope.102dCVE-2026-644207.0 ALT1.7%
——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-2021-0926—1.7%
——1——CVE-2024-320097.8 ALT1.7%
——1A vulnerability has been identified in Spectrum Power 4 (All versions < V4.70 SP12 Update 2). The affected application is vulnerable to a local privilege escalation due to wrongly set permissions to a binary which allows any local attacker to gain administrative privileges.11dCVE-2022-20037—1.7%
——1——CVE-2021-22549—1.7%
——1——CVE-2022-25832—1.7%
——1——CVE-2021-0894—1.7%
——1——CVE-2022-33276—1.7%
——1——CVE-2022-20036—1.7%
——1——CVE-2025-106844.3 MED1.7%
——1The Construction Light WordPress theme before 1.6.8 does not have authorisation and CSRF when activating via an AJAX action, allowing any authenticated users, such as subscriber to activate arbitrary .27dCVE-2026-168197.7 ALT1.7%
——1IBM AIX 7.2, and 7.3 and IBM PowerVM VIOS 4.1 could allow a local attacker to cause a denial of service and compromise data integrity due to a time-of-check time-of-use race condition.7dCVE-2026-872744.4 MED1.7%
——1Vulnerability in the Oracle VM VirtualBox product of Oracle Virtualization (component: Core). The supported version that is affected is 7.2.16. Difficult to exploit vulnerability allows low privileged attacker with logon to the infrastructure where Oracle VM VirtualBox executes to compromise Oracle VM VirtualBox. Successful attacks require human interaction from a person other than the attacker. Successful attacks of this vulnerability can result in unauthorized ability to cause a hang or frequently repeatable crash (complete DOS) of Oracle VM VirtualBox. CVSS 3.1 Base Score 4.4 (Availability impacts). CVSS Vector: (CVSS:3.1/AV:L/AC:H/PR:L/UI:R/S:U/C:N/I:N/A:H).41dCVE-2026-1050433.6 BAJ1.7%
——1MathWorks Simulink before R2026b, when showing a crafted .slx file, can have blocks that are never visible in the Simulink Editor but will cause code execution.28dCVE-2021-0445—1.7%
——1——CVE-2026-45907—1.7%
——1——CVE-2024-31415—1.7%
——1——CVE-2026-21128—1.7%
——1Improper input validation in CreditCardRegisterActivity of Samsung Checkout prior to version 5.1.03.1 allows local attackers to launch arbitrary activity with Samsung Checkout privileges.19dCVE-2023-23431—1.7%
——1——CVE-2025-95485.5 MED1.7%
——1A potential null pointer dereference vulnerability was reported in the Lenovo Power Management Driver that could allow a local authenticated user to cause a Windows blue screen error.26dCVE-2026-43050—1.7%
——1——CVE-2026-21115—1.7%
——1Out-of-bounds write in libcodec2-sec-flacdec.so prior to SMR Oct-2026 Release 1 allows local attackers to write out-of-bounds memory.18dCVE-2026-641905.5 MED1.7%
——1In the Linux kernel, the following vulnerability has been resolved:
net: team: fix NULL pointer dereference in team_xmit during mode change
__team_change_mode() clears team->ops with memset() before restoring
safe dummy handlers via team_adjust_ops(). A concurrent team_xmit()
running under RCU on another CPU can read team->ops.transmit during
this window and call a NULL function pointer, crashing the kernel.
The race requires a mode change (CAP_NET_ADMIN) concurrent with
transmit on the team device.
BUG: kernel NULL pointer dereference, address: 0000000000000000
Oops: 0010 [#1] SMP KASAN NOPTI
RIP: 0010:0x0
Call Trace:
team_xmit (drivers/net/team/team_core.c:1853)
dev_hard_start_xmit (net/core/dev.c:3904)
__dev_queue_xmit (net/core/dev.c:4871)
packet_sendmsg (net/packet/af_packet.c:3109)
__sys_sendto (net/socket.c:2265)
The original code assumed that no ports means no traffic, so mode
changes could freely memset()/memcpy() the ops. AF_PACKET with
forced carrier breaks that assumption.
Prevent the race instead of making it safe: replace memset()/memcpy()
with per-field updates that never touch transmit or receive. Those
two handlers are managed solely by team_adjust_ops(), which already
installs dummies when tx_en_port_count == 0 (always true during mode
change since no ports are present). WRITE_ONCE/READ_ONCE prevent
store/load tearing on the handler pointers.
synchronize_net() before exit_op() drains in-flight readers that may
still reference old mode state from before port removal switched the
handlers to dummies.4dCVE-2026-1187812.9 BAJ1.7%
——1Forge (also called node-forge) is a native implementation of Transport Layer Security in JavaScript. Prior to 1.4.1, the affected implementation used BigInteger.prototype.modInverse(), bnModInverse(), lib/jsbn.js, RSA public exponent e to process the relevant input or security decision. node-forge's bundled jsbn implementation entered an infinite loop when BigInteger.prototype.modInverse() received a negative value or modulus. An attacker who could control the RSA public exponent passed to key generation, or a direct modInverse() operand, could block the Node.js event loop at full CPU. Parsed DER, PEM, JWK, PKCS#12, X.509, and TLS values are unsigned and cannot trigger this issue. This issue is fixed in version 1.4.1.4dCVE-2026-980985.5 MED1.7%
——1In the Linux kernel, the following vulnerability has been resolved:
tipc: fix NULL deref in tipc_named_node_up() on empty publication list
User-space applications can bind a large number of service addresses to
one or more sockets. Each binding of a local-scope service address inserts
one entry (publication) into the TIPC name table. If the number of these
publications exceeds TIPC_MAX_PUBL (65535), protocol service types
(such as node state and link state) are no longer inserted into the name
table. This causes two issues:
1. User-space applications subscribing to node or link up/down events
stop receiving notifications.
2. A NULL pointer dereference can occur:
BUG: kernel NULL pointer dereference, address: 00000000000000d0
...
CPU: 0 UID: 0 PID: 0 Comm: swapper/0 Not tainted 7.2.0-rc4-default+ #5 PREEMPT(full)
...
RIP: 0010:tipc_named_node_up (./include/linux/skbuff.h:2251 net/tipc/name_distr.c:195 net/tipc/name_distr.c:221)
...
Call Trace:
<IRQ>
tipc_node_write_unlock (net/tipc/node.c:428)
tipc_rcv (net/tipc/node.c:934 net/tipc/node.c:2189)
tipc_udp_recv (net/tipc/udp_media.c:389)
Thread 1 (tipc_net_finalize) | Thread 2 (named_distribute)
-----------------------------|-----------------------------
| ...
| list_for_each_entry(publ, pls, binding_node) {
| ...
| __skb_queue_tail(list, skb);
| ...
| }
| ...
| hdr = buf_msg(skb_peek_tail(list));
... |
tipc_nametbl_publish(); |
If 'tipc_nametbl_publish()' (Thread 1) fails because the number of
local publications reaches TIPC_MAX_PUBL, list (Thread 2) will be empty. As a
result, NULL is passed to 'buf_msg()', leading to a NULL pointer dereference.
Fix these issues by allowing protocol service types (node state, link state,
and topology server) to be inserted into the name table unconditionally.
This ensures that users subscribing to these types always receive
notifications. In addition, the maximum number of local user publications is
reduced to (TIPC_MAX_PUBL - 1). This ensures that the maximum bulk size
calculated in tipc_link_set_queue_limits() remains valid.6dCVE-2025-27551—1.7%
——1——CVE-2021-0626—1.7%
——1——CVE-2026-580947.8 ALT1.7%
——1The FIOSSHMLPGCNF ioctl(2) operation configures the page size for a largepage shared memory object. This is intended to be used immediately after creating the object, before any memory is allocated for the object. The handler checked whether a page size had already been configured without holding the rangelock. Two concurrent callers could both observe an unconfigured object and set conflicting page sizes, leaving the object in an inconsistent state.
An unprivileged local user can exploit this race to escalate privileges.40dCVE-2026-317037.8 ALT1.7%
——1In the Linux kernel, the following vulnerability has been resolved:
writeback: Fix use after free in inode_switch_wbs_work_fn()
inode_switch_wbs_work_fn() has a loop like:
wb_get(new_wb);
while (1) {
list = llist_del_all(&new_wb->switch_wbs_ctxs);
/* Nothing to do? */
if (!list)
break;
... process the items ...
}
Now adding of items to the list looks like:
wb_queue_isw()
if (llist_add(&isw->list, &wb->switch_wbs_ctxs))
queue_work(isw_wq, &wb->switch_work);
Because inode_switch_wbs_work_fn() loops when processing isw items, it
can happen that wb->switch_work is pending while wb->switch_wbs_ctxs is
empty. This is a problem because in that case wb can get freed (no isw
items -> no wb reference) while the work is still pending causing
use-after-free issues.
We cannot just fix this by cancelling work when freeing wb because that
could still trigger problematic 0 -> 1 transitions on wb refcount due to
wb_get() in inode_switch_wbs_work_fn(). It could be all handled with
more careful code but that seems unnecessarily complex so let's avoid
that until it is proven that the looping actually brings practical
benefit. Just remove the loop from inode_switch_wbs_work_fn() instead.
That way when wb_queue_isw() queues work, we are guaranteed we have
added the first item to wb->switch_wbs_ctxs and nobody is going to
remove it (and drop the wb reference it holds) until the queued work
runs.102dCVE-2026-532265.5 MED1.7%
——1In the Linux kernel, the following vulnerability has been resolved:
gpio: rockchip: fix generic IRQ chip leak on remove
The driver allocates domain generic chips using
irq_alloc_domain_generic_chips() during probe. However, on driver
remove/teardown, the generic chips are not automatically freed when the
IRQ domain is removed because the domain flags do not include
IRQ_DOMAIN_FLAG_DESTROY_GC.
This causes both the domain generic chips structure and the associated
generic chips to be leaked. Additionally, the generic chips remain on
the global gc_list and may later be visited by generic IRQ chip suspend,
resume, or shutdown callbacks after the GPIO bank has been removed,
potentially resulting in a use-after-free and kernel crash.
Fix the resource leak by explicitly calling
irq_domain_remove_generic_chips() before removing the IRQ domain in
rockchip_gpio_remove().108dCVE-2026-462265.5 MED1.7%
——1In the Linux kernel, the following vulnerability has been resolved:
spi: fsl: fix controller deregistration
Make sure to deregister the controller before releasing underlying
resources like DMA during driver unbind.4dCVE-2026-24926—1.7%
——1——CVE-2021-0658—1.7%
——1——CVE-2026-30902—1.7%
——1——