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,354
- Bajo528
Ventana
Severidad
Filtros
CVECVSSEPSSKEVRExplotTítuloVis.
CVE-2026-43297—2.2%
——1——CVE-2026-31725—2.2%
——1——CVE-2026-31639—2.2%
——1——CVE-2026-31560—2.2%
——1——CVE-2026-43081—2.2%
——1——CVE-2026-43444—2.2%
——1——CVE-2026-43354—2.2%
——1——CVE-2026-31593—2.2%
——1——CVE-2026-530135.5 MED2.2%
——1In the Linux kernel, the following vulnerability has been resolved:
macvlan: fix macvlan_get_size() not reserving space for IFLA_MACVLAN_BC_CUTOFF
macvlan_get_size() does not account for IFLA_MACVLAN_BC_CUTOFF, but
macvlan_fill_info() conditionally includes it when port->bc_cutoff != 1.
This causes nla_put_s32() to fail with -EMSGSIZE when the netlink skb
runs out of space, triggering a WARN_ON in rtnetlink and preventing the
interface from being dumped.
The bug can be reproduced with:
ip link add macvlan0 link eth0 type macvlan mode bridge
ip link set macvlan0 type macvlan bc_cutoff 0
ip -d link show macvlan0 # fails with -EMSGSIZE
The bc_cutoff feature was added in commit 954d1fa1ac93 ("macvlan: Add
netlink attribute for broadcast cutoff"), which added the nla_put_s32()
call in macvlan_fill_info() but missed adding the corresponding
nla_total_size(4) in macvlan_get_size(). A follow-up commit
55cef78c244d ("macvlan: add forgotten nla_policy for
IFLA_MACVLAN_BC_CUTOFF") fixed the missing nla_policy entry but still
did not fix the size calculation.49dCVE-2026-43092—2.2%
——1——CVE-2025-12690—2.2%
——1——CVE-2026-43300—2.2%
——1——CVE-2026-31724—2.2%
——1——CVE-2026-31458—2.2%
——1——CVE-2026-715768.5 ALT2.2%
——1A flaw was found in multicluster-global-hub. The manager component improperly validates the source identity of incoming CloudEvents on Kafka status topics. A remote attacker, after compromising a managed hub and obtaining its Kafka client certificate, can manipulate the self-asserted source identity. This allows the attacker to falsify or delete critical data, such as compliance, inventory, and cluster health information, belonging to other hubs in the database.18dCVE-2026-43129—2.2%
——1——CVE-2026-234645.5 MED2.2%
——1In the Linux kernel, the following vulnerability has been resolved:
soc: microchip: mpfs: Fix memory leak in mpfs_sys_controller_probe()
In mpfs_sys_controller_probe(), if of_get_mtd_device_by_node() fails,
the function returns immediately without freeing the allocated memory
for sys_controller, leading to a memory leak.
Fix this by jumping to the out_free label to ensure the memory is
properly freed.
Also, consolidate the error handling for the mbox_request_channel()
failure case to use the same label.39dCVE-2026-23316—2.2%
——1——CVE-2024-31335—2.2%
——1——CVE-2026-31736—2.2%
——1——CVE-2026-31645—2.2%
——1——CVE-2026-43397—2.2%
——1——CVE-2026-46139—2.2%
——1——CVE-2026-31575—2.2%
——1——CVE-2026-43306—2.2%
——1——CVE-2026-45950—2.2%
——1——CVE-2026-43167—2.2%
——1——CVE-2026-46073—2.2%
——1——CVE-2026-31740—2.2%
——1——CVE-2026-31741—2.2%
——1——CVE-2026-23135—2.2%
——1——CVE-2026-43393—2.2%
——1——CVE-2025-11567—2.2%
——1——CVE-2026-31561—2.2%
——1——CVE-2026-23138—2.2%
——1——CVE-2026-6522—2.2%
——1——CVE-2026-0064—2.2%
——1——CVE-2026-317325.5 MED2.2%
——1In the Linux kernel, the following vulnerability has been resolved:
gpio: Fix resource leaks on errors in gpiochip_add_data_with_key()
Since commit aab5c6f20023 ("gpio: set device type for GPIO chips"),
`gdev->dev.release` is unset. As a result, the reference count to
`gdev->dev` isn't dropped on the error handling paths.
Drop the reference on errors.
Also reorder the instructions to make the error handling simpler.
Now gpiochip_add_data_with_key() roughly looks like:
>>> Some memory allocation. Go to ERR ZONE 1 on errors.
>>> device_initialize().
gpiodev_release() takes over the responsibility for freeing the
resources of `gdev->dev`. The subsequent error handling paths
shouldn't go through ERR ZONE 1 again which leads to double free.
>>> Some initialization mainly on `gdev`.
>>> The rest of initialization. Go to ERR ZONE 2 on errors.
>>> Chip registration success and exit.
>>> ERR ZONE 2. gpio_device_put() and exit.
>>> ERR ZONE 1.59dCVE-2026-530145.5 MED2.2%
——1In the Linux kernel, the following vulnerability has been resolved:
net/sched: act_mirred: fix wrong device for mac_header_xmit check in tcf_blockcast_redir
In tcf_blockcast_redir(), when iterating block ports to redirect
packets to multiple devices, the mac_header_xmit flag is queried
from the wrong device. The loop sends to dev_prev but queries
dev_is_mac_header_xmit(dev) — which is the NEXT device in the
iteration, not the one being sent to.
This causes tcf_mirred_to_dev() to make incorrect decisions about
whether to push or pull the MAC header. When the block contains
mixed device types (e.g., an ethernet veth and a tunnel device),
intermediate devices get the wrong mac_header_xmit flag, leading to
skb header corruption. In the worst case, skb_push_rcsum with an
incorrect mac_len can exhaust headroom and panic.
The last device in the loop is handled correctly (line 365-366 uses
dev_is_mac_header_xmit(dev_prev)), confirming this is a copy-paste
oversight for the intermediate devices.
Fix by using dev_prev instead of dev for the mac_header_xmit query,
consistent with the device actually being sent to.48dCVE-2026-530817.8 ALT2.2%
——1In the Linux kernel, the following vulnerability has been resolved:
bpf: Enforce regsafe base id consistency for BPF_ADD_CONST scalars
When regsafe() compares two scalar registers that both carry
BPF_ADD_CONST, check_scalar_ids() maps their full compound id
(aka base | BPF_ADD_CONST flag) as one idmap entry. However,
it never verifies that the underlying base ids, that is, with
the flag stripped are consistent with existing idmap mappings.
This allows construction of two verifier states where the old
state has R3 = R2 + 10 (both sharing base id A) while the current
state has R3 = R4 + 10 (base id C, unrelated to R2). The idmap
creates two independent entries: A->B (for R2) and A|flag->C|flag
(for R3), without catching that A->C conflicts with A->B. State
pruning then incorrectly succeeds.
Fix this by additionally verifying base ID mapping consistency
whenever BPF_ADD_CONST is set: after mapping the compound ids,
also invoke check_ids() on the base IDs (flag bits stripped).
This ensures that if A was already mapped to B from comparing
the source register, any ADD_CONST derivative must also derive
from B, not an unrelated C.40d