Vulnerabilidades explotables hoy
368,208en 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,694
Nuevos KEV · 24H0
Exploit Today ≥ 701,631
Distribución · última ventana
- Crítico2,147
- Alto7,679
- Medio5,506
- Bajo542
Ventana
Severidad
Filtros
CVECVSSEPSSKEVRExplotTítuloVis.
CVE-2025-26549—4.0%
——1——CVE-2023-5339—4.0%
——1——CVE-2026-805519.3 CRÍ4.0%
——1In the Linux kernel, the following vulnerability has been resolved:
s390/vfio_ccw: Ensure first IDAW remains constant
The first IDAW in a list does not need to be on a 2K/4K boundary
like all others, and so is read separately to accurately calculate
the size of the buffer needed to read the full IDAL.
Verify that the address found in the first IDAW is unchanged between
reads, to ensure a consistent set of IDAWs being worked with.8dCVE-2026-31368—4.0%
——1——CVE-2025-30238—4.0%
——1In affected TP-Link Aginet devices, insufficient
authorization validation allows authenticated low-privileged users to execute higher-privileged
operations.
An attacker
may perform administrative actions such as creating privileged accounts or
modifying critical configuration settings.17dCVE-2025-26547—4.0%
——1——CVE-2023-53060—4.0%
——1——CVE-2023-31014—4.0%
——1——CVE-2025-38340—4.0%
——1——CVE-2025-62123—4.0%
——1——CVE-2026-45028—4.0%
——1——CVE-2026-45961—4.0%
——1——CVE-2025-26931—4.0%
——1——CVE-2025-13176—4.0%
——1——CVE-2024-13177—4.0%
——1——CVE-2022-39904—4.0%
——1——CVE-2025-13397—4.0%
——1——CVE-2025-399577.1 ALT4.0%
——1In the Linux kernel, the following vulnerability has been resolved:
wifi: mac80211: increase scan_ies_len for S1G
Currently the S1G capability element is not taken into account
for the scan_ies_len, which leads to a buffer length validation
failure in ieee80211_prep_hw_scan() and subsequent WARN in
__ieee80211_start_scan(). This prevents hw scanning from functioning.
To fix ensure we accommodate for the S1G capability length.36dCVE-2024-44956—4.0%
——1——CVE-2026-348835.3 MED4.0%
——1An issue was discovered in the Portrait Dell Color Management application before 3.7.0 for Dell monitors. On Windows, a symbolic link vulnerability allows a local low-privileged user to escalate privileges to Administrator. During installation, the software writes the file CCFLFamily_07Feb11.edr to C:\ProgramData\Portrait Displays\CW\data\i1D3\ while running with elevated privileges. Because the installer does not properly validate symbolic links or reparse points at the destination path, an attacker can create a malicious link that redirects the write operation to an arbitrary system location, enabling arbitrary file creation or overwrite with elevated privileges.42dCVE-2025-26759—4.0%
——1——CVE-2025-1102—4.0%
——1——CVE-2023-53657—4.0%
——1——CVE-2026-33372—4.0%
——1——CVE-2025-53869—4.0%
——1——CVE-2024-38303—4.0%
——1——CVE-2026-776587.8 ALT4.0%
——1A stack-based buffer overflow vulnerability exists in the Dia diagram editor when processing Network Bus objects from Dia XML project files.
In objects/network/bus.c, bus_load() reads the number of bus handles from the file attribute "bus_handles" using attribute_num_data() without validating an upper bound:
bus->num_handles = attribute_num_data(attr);
When a bus handle is subsequently moved, bus_handle_moved() allocates two temporary arrays on the stack:
parallel = (real *)g_alloca(num_handles * sizeof(real));
perp = (real *)g_alloca(num_handles * sizeof(real));
Because num_handles is fully attacker-controlled via the project file, sufficiently large values (for example 262144 or higher) cause g_alloca() to consume more stack space than the default thread stack limit (typically 8 MB on Linux), resulting in stack overflow, SIGSEGV, and potential stack frame / return-address corruption.
An attacker can embed a Bus object with an excessive bus_handles count in a malicious .dia file. Exploitation requires the victim to open the file in Dia (file dialog, command line, or file association) and trigger handle manipulation (moving a bus handle), which exercises the vulnerable code path.
The identical g_alloca pattern is present in objects/Misc/tree.c (copied from bus.c) and is likely vulnerable to the same class of attack via Tree objects.
Affected versions: Dia 0.98.0 and earlier versions containing this code; issue confirmed on upstream master as of 2026-08-21.
Upstream report: https://gitlab.gnome.org/GNOME/dia/-/issues/5816dCVE-2025-52925—4.0%
——1——CVE-2022-50976—4.0%
——1——CVE-2025-26545—4.0%
——1——CVE-2026-27937—4.0%
——1——CVE-2025-400247.8 ALT4.0%
——1In the Linux kernel, the following vulnerability has been resolved:
vhost: Take a reference on the task in struct vhost_task.
vhost_task_create() creates a task and keeps a reference to its
task_struct. That task may exit early via a signal and its task_struct
will be released.
A pending vhost_task_wake() will then attempt to wake the task and
access a task_struct which is no longer there.
Acquire a reference on the task_struct while creating the thread and
release the reference while the struct vhost_task itself is removed.
If the task exits early due to a signal, then the vhost_task_wake() will
still access a valid task_struct. The wake is safe and will be skipped
in this case.36dCVE-2025-10721—4.0%
——1——CVE-2026-805549.3 CRÍ4.0%
——1In the Linux kernel, the following vulnerability has been resolved:
s390/vfio_ccw: Limit the number of channel program segments
The processing of channel programs, and the CCWs within them, is done
recursively. As such, there is an arbitrary (but not architectural)
limit to the number of CCWs that can exist in a single channel program.
The vfio-ccw logic breaks these channel programs into segments whenever
it encounters a Transfer-In-Channel (TIC) CCW, and the combined number
of segments count towards the global limit. Impose an equivalent limit
to the number of segments until such logic can be made non-recursive.8dCVE-2026-84141—4.0%
——1Integer overflow in the Graphics: ImageLib component. This vulnerability was fixed in Firefox 155, Firefox ESR 153.2, Thunderbird 155, and Thunderbird 153.2.2dCVE-2025-384857.8 ALT4.0%
——1In the Linux kernel, the following vulnerability has been resolved:
iio: accel: fxls8962af: Fix use after free in fxls8962af_fifo_flush
fxls8962af_fifo_flush() uses indio_dev->active_scan_mask (with
iio_for_each_active_channel()) without making sure the indio_dev
stays in buffer mode.
There is a race if indio_dev exits buffer mode in the middle of the
interrupt that flushes the fifo. Fix this by calling
synchronize_irq() to ensure that no interrupt is currently running when
disabling buffer mode.
Unable to handle kernel NULL pointer dereference at virtual address 00000000 when read
[...]
_find_first_bit_le from fxls8962af_fifo_flush+0x17c/0x290
fxls8962af_fifo_flush from fxls8962af_interrupt+0x80/0x178
fxls8962af_interrupt from irq_thread_fn+0x1c/0x7c
irq_thread_fn from irq_thread+0x110/0x1f4
irq_thread from kthread+0xe0/0xfc
kthread from ret_from_fork+0x14/0x2c36dCVE-2025-402017.8 ALT4.0%
——1In the Linux kernel, the following vulnerability has been resolved:
kernel/sys.c: fix the racy usage of task_lock(tsk->group_leader) in sys_prlimit64() paths
The usage of task_lock(tsk->group_leader) in sys_prlimit64()->do_prlimit()
path is very broken.
sys_prlimit64() does get_task_struct(tsk) but this only protects task_struct
itself. If tsk != current and tsk is not a leader, this process can exit/exec
and task_lock(tsk->group_leader) may use the already freed task_struct.
Another problem is that sys_prlimit64() can race with mt-exec which changes
->group_leader. In this case do_prlimit() may take the wrong lock, or (worse)
->group_leader may change between task_lock() and task_unlock().
Change sys_prlimit64() to take tasklist_lock when necessary. This is not
nice, but I don't see a better fix for -stable.36dCVE-2026-480818.1 ALT4.0%
——1OpenReception's appointment booking software provides an end-to-end encrypted appointment booking platform. Prior to version 1.0.2, a TENANT_ADMIN can store `javascript:` URLs in the tenant `links` configuration (`website`, `imprint`, `privacyStatement`). These values are returned to the patient-facing landing page via `/api/public`, hydrated into the SvelteKit Button component, and rendered as `<a href="javascript:...">` elements without URL-scheme filtering. A patient who clicks any such link executes the attacker's JavaScript inside the patient browser origin, where patient form data is read before client-side encryption is applied. This breaks the project's central trust claim that the server is an untrusted relay and that administrators cannot read patient data. Patient-side encryption happens after form input, so JavaScript executing in the patient origin can read or alter the plaintext before encryption is performed. Version 1.0.2 fixes the issue.27dCVE-2025-400957.8 ALT4.0%
——1In the Linux kernel, the following vulnerability has been resolved:
usb: gadget: f_rndis: Refactor bind path to use __free()
After an bind/unbind cycle, the rndis->notify_req is left stale. If a
subsequent bind fails, the unified error label attempts to free this
stale request, leading to a NULL pointer dereference when accessing
ep->ops->free_request.
Refactor the error handling in the bind path to use the __free()
automatic cleanup mechanism.36dCVE-2026-640097.8 ALT4.0%
——1In the Linux kernel, the following vulnerability has been resolved:
xfrm: Check for underflow in xfrm_state_mtu
Leo Lin reported OOB write issue in esp component:
xfrm_state_mtu() returns u32 but performs its arithmetic in unsigned
modulo-2^32 space using an attacker-influenced "header_len + authsize +
net_adj" subtracted from a small "mtu" argument. A nobody user can
install an IPv4 ESP tunnel SA with a large authentication key
(XFRMA_ALG_AUTH_TRUNC, e.g. hmac(sha512), 64-byte key, 64-byte trunc),
configure a small interface MTU (68 bytes), and set XFRMA_TFCPAD to a
large value. When a single UDP datagram is then sent through the
tunnel, xfrm_state_mtu() underflows to a near-2^32 value, and
esp_output() consumes it as a signed int via:
padto = min(x->tfcpad, xfrm_state_mtu(x, mtu_cached))
esp.tfclen = padto - skb->len (assigned to int)
esp.tfclen ends up negative (e.g. -207). It is sign-extended to size_t
when passed to memset() inside esp_output_fill_trailer(), producing a
~16 EB write of zeroes at skb_tail_pointer(skb). KASAN logs it as
"Write of size 18446744073709551537 at addr ffff888...".
Check for underflow and return 1. This causes the sendmsg attempt to
fail with ENETUNREACH.36d