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,274
- Alto9,334
- Medio5,332
- Bajo522
Ventana
Severidad
Filtros
CVECVSSEPSSKEVRExplotTítuloVis.
CVE-2026-281455.3 MED1.3%
——0Insufficient Verification of Data Authenticity vulnerability in StylemixThemes MasterStudy LMS allows Manipulating User State.
This issue affects MasterStudy LMS: from n/a through 3.7.39.19dCVE-2021-0680—1.3%
——0——CVE-2026-00563.3 BAJ1.3%
——0In setTo of ResourceTypes.cpp, there is a possible read out of bounds due to an incorrect bounds check. This could lead to local information disclosure with no additional execution privileges needed. User interaction is not needed for exploitation.41dCVE-2024-45566—1.3%
——0——CVE-2023-28006—1.3%
——0——CVE-2022-20319—1.3%
——0——CVE-2026-23147—1.3%
——0——CVE-2025-13755—1.3%
——0——CVE-2024-51527—1.3%
——0——CVE-2026-3588—1.3%
——0——CVE-2023-535207.8 ALT1.3%
——0In the Linux kernel, the following vulnerability has been resolved:
Bluetooth: Fix hci_suspend_sync crash
If hci_unregister_dev() frees the hci_dev object but hci_suspend_notifier
may still be accessing it, it can cause the program to crash.
Here's the call trace:
<4>[102152.653246] Call Trace:
<4>[102152.653254] hci_suspend_sync+0x109/0x301 [bluetooth]
<4>[102152.653259] hci_suspend_dev+0x78/0xcd [bluetooth]
<4>[102152.653263] hci_suspend_notifier+0x42/0x7a [bluetooth]
<4>[102152.653268] notifier_call_chain+0x43/0x6b
<4>[102152.653271] __blocking_notifier_call_chain+0x48/0x69
<4>[102152.653273] __pm_notifier_call_chain+0x22/0x39
<4>[102152.653276] pm_suspend+0x287/0x57c
<4>[102152.653278] state_store+0xae/0xe5
<4>[102152.653281] kernfs_fop_write+0x109/0x173
<4>[102152.653284] __vfs_write+0x16f/0x1a2
<4>[102152.653287] ? selinux_file_permission+0xca/0x16f
<4>[102152.653289] ? security_file_permission+0x36/0x109
<4>[102152.653291] vfs_write+0x114/0x21d
<4>[102152.653293] __x64_sys_write+0x7b/0xdb
<4>[102152.653296] do_syscall_64+0x59/0x194
<4>[102152.653299] entry_SYSCALL_64_after_hwframe+0x5c/0xc1
This patch holds the reference count of the hci_dev object while
processing it in hci_suspend_notifier to avoid potential crash
caused by the race condition.28dCVE-2026-642155.5 MED1.3%
——0In the Linux kernel, the following vulnerability has been resolved:
drm/msm/a6xx: Check kzalloc return in a8xx_hfi_send_perf_table
Check the return value of kzalloc() to prevent a NULL pointer
dereference on allocation failure.
Patchwork: https://patchwork.freedesktop.org/patch/721342/20dCVE-2024-56456—1.3%
——0——CVE-2019-25343—1.3%
——0——CVE-2026-46685—1.3%
——0——CVE-2023-28571—1.3%
——0——CVE-2026-7994—1.3%
——0——CVE-2026-7257—1.3%
——0——CVE-2023-21256—1.3%
——0——CVE-2026-462455.5 MED1.3%
——0In the Linux kernel, the following vulnerability has been resolved:
drm/amd/display: Fix dc_link NULL handling in HPD init
amdgpu_dm_hpd_init() may see connectors without a valid dc_link.
The code already checks dc_link for the polling decision, but later
unconditionally dereferences it when setting up HPD interrupts.
Assign dc_link early and skip connectors where it is NULL.
Fixes the below:
drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm_irq.c:940 amdgpu_dm_hpd_init()
error: we previously assumed 'dc_link' could be null (see line 931)
drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm_irq.c
923 /*
924 * Analog connectors may be hot-plugged unlike other connector
925 * types that don't support HPD. Only poll analog connectors.
926 */
927 use_polling |=
928 amdgpu_dm_connector->dc_link &&
^^^^^^^^^^^^^^^^^^^^^^^^^^^^ The patch adds this NULL check but hopefully it can be removed
929 dc_connector_supports_analog(amdgpu_dm_connector->dc_link->link_id.id);
930
931 dc_link = amdgpu_dm_connector->dc_link;
dc_link assigned here.
932
933 /*
934 * Get a base driver irq reference for hpd ints for the lifetime
935 * of dm. Note that only hpd interrupt types are registered with
936 * base driver; hpd_rx types aren't. IOW, amdgpu_irq_get/put on
937 * hpd_rx isn't available. DM currently controls hpd_rx
938 * explicitly with dc_interrupt_set()
939 */
--> 940 if (dc_link->irq_source_hpd != DC_IRQ_SOURCE_INVALID) {
^^^^^^^^^^^^^^^^^^^^^^^ If it's NULL then we are trouble because we dereference it here.
941 irq_type = dc_link->irq_source_hpd - DC_IRQ_SOURCE_HPD1;
942 /*
943 * TODO: There's a mismatch between mode_info.num_hpd
944 * and what bios reports as the # of connectors with hpd40dCVE-2026-28689—1.3%
——0——CVE-2025-42888—1.3%
——0——CVE-2025-59131—1.3%
——0——CVE-2025-58131—1.3%
——0——CVE-2024-45564—1.3%
——0——CVE-2022-20095—1.3%
——0——CVE-2025-25058—1.3%
——0——CVE-2026-35603—1.3%
——0——CVE-2026-769245.5 MED1.3%
——0Kerberos protocol dissector crash in 4.6.0 to 4.6.7 and 4.4.0 to 4.4.18 allows denial of service3dCVE-2020-0428—1.3%
——0——CVE-2025-66003—1.3%
——0——CVE-2025-68467—1.3%
——0——CVE-2026-531025.5 MED1.3%
——0In the Linux kernel, the following vulnerability has been resolved:
wifi: mt76: Fix memory leak after mt76_connac_mcu_alloc_sta_req()
mt76_connac_mcu_alloc_sta_req() allocates an skb which is expected to
be freed eventually by mt76_mcu_skb_send_msg(). However, currently if
an intermediate function fails before sending, the allocated skb is
leaked.
Specifically, mt76_connac_mcu_sta_wed_update() and
mt76_connac_mcu_sta_key_tlv() may fail, leading to an immediate memory
leak in the error path.
Fix this by explicitly freeing the skb in these error paths.
Commit 7c0f63fe37a5 ("wifi: mt76: mt7996: fix memory leak on
mt7996_mcu_sta_key_tlv error") made a similar change.
Compile tested only. Issue found using a prototype static analysis tool
and code review.41dCVE-2024-45577—1.3%
——0——CVE-2026-442766.0 MED1.3%
——0Dell PowerProtect Data Manager, versions prior to 20.2.0.0, contain(s) an Exposure of Sensitive Information to an Unauthorized Actor vulnerability in the REST API. A high privileged attacker with local access could potentially exploit this vulnerability, leading to Information exposure.33dCVE-2024-56454—1.3%
——0——CVE-2024-56453—1.3%
——0——CVE-2025-21027—1.3%
——0——CVE-2023-33111—1.3%
——0——CVE-2025-7433—1.3%
——0——