Vulnerabilidades explotables hoy
367,165en 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,263
- Alto9,268
- Medio5,273
- Bajo508
Ventana
Severidad
Filtros
CVECVSSEPSSKEVRExplotTítuloVis.
CVE-2017-9718—0.8%
——0——CVE-2026-418597.8 ALT0.8%
——0A network man-in-the-middle between nats-sync and the BOSH director can steal the director credentials (Basic auth header or UAA client secret) and can tamper with the VM list that is written into the NATS authorization file. Stolen credentials grant administrative director access. UsersSync#bosh_api_response_body builds a Net::HTTP client with verify_mode = OpenSSL::SSL::VERIFY_NONE for every director call (/info, /deployments, /deployments/<name>/vms).
Affected versions:
- BOSH: all versions prior to v282.1.9 (inclusive); fixed in v282.1.9 or later40dCVE-2025-13905—0.8%
——0——CVE-2017-11045—0.8%
——0——CVE-2022-26463—0.8%
——0——CVE-2022-26459—0.8%
——0——CVE-2023-21172—0.8%
——0——CVE-2023-20701—0.8%
——0——CVE-2026-566094.8 MED0.8%
——0HCL iControl is affected by Weak SSL/TLS Version Supported vulnerability. It was observed that the application was using weak TLS versions such as TLS 1.0 and 1.1. These outdated protocols lack modern security features, making them vulnerable to known attacks and exposing sensitive information during data transmission.26dCVE-2025-54613—0.8%
——0——CVE-2023-31313—0.8%
——0——CVE-2023-21174—0.8%
——0——CVE-2025-47389—0.8%
——0——CVE-2026-47335—0.8%
——0——CVE-2026-240897.2 ALT0.8%
——0Memory corruption while processing fastboot commands with invalid input.40dCVE-2023-21182—0.8%
——0——CVE-2023-21483—0.8%
——0——CVE-2025-27940—0.8%
——0——CVE-2024-22447—0.8%
——0——CVE-2023-35686—0.8%
——0——CVE-2021-25515—0.8%
——0——CVE-2026-25014—0.8%
——0——CVE-2026-33452—0.8%
——0——CVE-2025-9383—0.8%
——0——CVE-2026-27090—0.8%
——0——CVE-2025-48904—0.8%
——0——CVE-2026-240857.2 ALT0.8%
——0Memory Corruption when processing display command line information due to improper initialization of a variable.40dCVE-2023-21041—0.8%
——0——CVE-2022-25679—0.8%
——0——CVE-2026-20914—0.8%
——0——CVE-2023-43517—0.8%
——0——CVE-2023-24844—0.8%
——0——CVE-2026-31959—0.8%
——0——CVE-2026-77970—0.8%
——0Cleartext Storage of Sensitive Information vulnerability in ash-project ash_paper_trail allows an attacker with read access to the generated version resource to recover sensitive values nested inside embedded resources, unions, or lists.
sensitive_attributes :redact and :ignore only act on the tracked resource's top-level attributes. maybe_redact_changes/3 and the stored-action-input path in AshPaperTrail.Resource.Changes.CreateNewVersion derive the sensitive set from the resource's own attributes and never descend into embedded, union, or list values, so a non-sensitive attribute or action argument that holds an embed with a sensitive? field (for example an accepted credentials embed carrying a token) is written to the version table in cleartext.
This issue affects ash_paper_trail: from 0.3.0 before 0.7.0.2dCVE-2026-641005.5 MED0.8%
——0In the Linux kernel, the following vulnerability has been resolved:
drm/msm: Fix shrinker deadlock
With PROVE_LOCKING on an Snapdragon X1 and VM reclaim pressure, we see:
======================================================
WARNING: possible circular locking dependency detected
7.0.0-debug+ #43 Tainted: G W
------------------------------------------------------
kswapd0/82 is trying to acquire lock:
ffff800080ec3870 (reservation_ww_class_acquire){+.+.}-{0:0}, at: msm_gem_shrinker_scan+0x17c/0x400 [msm]
but task is already holding lock:
ffffc31709b263b8 (fs_reclaim){+.+.}-{0:0}, at: balance_pgdat+0x88/0x988
which lock already depends on the new lock.
the existing dependency chain (in reverse order) is:
-> #2 (fs_reclaim){+.+.}-{0:0}:
__lock_acquire+0x4d0/0xad0
lock_acquire.part.0+0xc4/0x248
lock_acquire+0x8c/0x248
fs_reclaim_acquire+0xd0/0xf0
dma_resv_lockdep+0x224/0x348
do_one_initcall+0x84/0x5d0
do_initcalls+0x194/0x1d8
kernel_init_freeable+0x128/0x180
kernel_init+0x2c/0x160
ret_from_fork+0x10/0x20
-> #1 (reservation_ww_class_mutex){+.+.}-{4:4}:
__lock_acquire+0x4d0/0xad0
lock_acquire.part.0+0xc4/0x248
lock_acquire+0x8c/0x248
dma_resv_lockdep+0x1a8/0x348
do_one_initcall+0x84/0x5d0
do_initcalls+0x194/0x1d8
kernel_init_freeable+0x128/0x180
kernel_init+0x2c/0x160
ret_from_fork+0x10/0x20
-> #0 (reservation_ww_class_acquire){+.+.}-{0:0}:
check_prev_add+0x114/0x790
validate_chain+0x594/0x6f0
__lock_acquire+0x4d0/0xad0
lock_acquire.part.0+0xc4/0x248
lock_acquire+0x8c/0x248
drm_gem_lru_scan+0x1ac/0x440
msm_gem_shrinker_scan+0x17c/0x400 [msm]
do_shrink_slab+0x150/0x4a0
shrink_slab+0x144/0x460
shrink_one+0x9c/0x1b0
shrink_many+0x27c/0x5c0
shrink_node+0x344/0x550
balance_pgdat+0x2c0/0x988
kswapd+0x11c/0x318
kthread+0x10c/0x128
ret_from_fork+0x10/0x20
other info that might help us debug this:
Chain exists of:
reservation_ww_class_acquire --> reservation_ww_class_mutex --> fs_reclaim
Possible unsafe locking scenario:
CPU0 CPU1
---- ----
lock(fs_reclaim);
lock(reservation_ww_class_mutex);
lock(fs_reclaim);
lock(reservation_ww_class_acquire);
*** DEADLOCK ***
1 lock held by kswapd0/82:
#0: ffffc31709b263b8 (fs_reclaim){+.+.}-{0:0}, at: balance_pgdat+0x88/0x988
stack backtrace:
CPU: 4 UID: 0 PID: 82 Comm: kswapd0 Tainted: G W 7.0.0-debug+ #43 PREEMPT(full)
Tainted: [W]=WARN
Hardware name: LENOVO 21BX0016US/21BX0016US, BIOS N3HET94W (1.66 ) 09/15/2025
Call trace:
show_stack+0x20/0x40 (C)
dump_stack_lvl+0x9c/0xd0
dump_stack+0x18/0x30
print_circular_bug+0x114/0x120
check_noncircular+0x178/0x198
check_prev_add+0x114/0x790
validate_chain+0x594/0x6f0
__lock_acquire+0x4d0/0xad0
lock_acquire.part.0+0xc4/0x248
lock_acquire+0x8c/0x248
drm_gem_lru_scan+0x1ac/0x440
msm_gem_shrinker_scan+0x17c/0x400 [msm]
do_shrink_slab+0x150/0x4a0
shrink_slab+0x144/0x460
shrink_one+0x9c/0x1b0
shrink_many+0x27c/0x5c0
shrink_node+0x344/0x550
balance_pgdat+0x2c0/0x988
kswapd+0x11c/0x318
kthread+0x10c/0x128
ret_from_fork+0x10/0x20
kswapd0 holding fs_reclaim calls the MSM shrinker, which calls
dma_resv_lock. This in turn acquires fs_reclaim.
Fix this deadlock by using dma_resv_trylock() instead, dropping the
subsequently unused passed wait-wound lock 'ticket'.
Patchwork: https://patchwork.freedesktop.org/patch/723564/
[rob: fixup compile errors, replace lockdep splat with somethin
---truncated---20dCVE-2026-664744.3 MED0.8%
——0Unauthenticated Cross Site Request Forgery (CSRF) in Insert Headers and Footers Code – HT Script <= 1.1.8 versions.35dCVE-2016-10394—0.8%
——0——CVE-2024-45447—0.8%
——0——CVE-2024-7142—0.8%
——0——CVE-2023-21151—0.8%
——0——