Vulnerabilidades explotables hoy
414,784en 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,781
Nuevos KEV · 24H0
Exploit Today ≥ 701,709
Distribución · última ventana
- Crítico5,284
- Alto20,832
- Medio19,524
- Bajo2,048
Filtros
Ventana
Severidad
Filtros
CVECVSSEPSSKEVRExplotTítuloVis.
CVE-2002-1981—91.8%
——28——CVE-2016-8618—91.8%
——28——CVE-2022-43030—91.8%
——28——CVE-2004-1274—91.8%
——28——CVE-2006-1876—91.8%
——28——CVE-2022-34125—91.8%
——28——CVE-2006-6865—91.8%
——28——CVE-2000-0026—91.8%
——28——CVE-2012-0668—91.8%
——28——CVE-2005-2472—91.8%
——28——CVE-2009-3377—91.8%
——28——CVE-2012-3174—91.8%
——28——CVE-2021-32835—91.8%
——28——CVE-2006-3887—91.8%
——28——CVE-2025-152295.3 MED91.8%
——28A vulnerability has been found in Tenda CH22 up to 1.0.0.1. Affected by this vulnerability is the function fromDhcpListClient of the file /goform/DhcpListClient. Such manipulation of the argument LISTLEN leads to denial of service. The attack may be launched remotely. The exploit has been disclosed to the public and may be used.39dCVE-2010-0600—91.8%
——28——CVE-2003-0496—91.8%
——28——CVE-2004-0391—91.8%
——28——CVE-2025-544038.8 ALT91.8%
——28Multiple OS command injection vulnerabilities exist in the swctrl functionality of Planet WGR-500 v1.3411b190912. A specially crafted network request can lead to arbitrary command execution. An attacker can send a network request to trigger these vulnerabilities.This command injection is related to the `new_password` request parameter.38dCVE-2007-6176—91.8%
——28——CVE-2026-2210—91.8%
——28——CVE-2018-5704—91.8%
——28——CVE-2024-16357.5 ALT91.8%
——28A vulnerability was found in Undertow. This vulnerability impacts a server that supports the wildfly-http-client protocol. Whenever a malicious user opens and closes a connection with the HTTP port of the server and then closes the connection immediately, the server will end with both memory and open file limits exhausted at some point, depending on the amount of memory available.
At HTTP upgrade to remoting, the WriteTimeoutStreamSinkConduit leaks connections if RemotingConnection is closed by Remoting ServerConnectionOpenListener. Because the remoting connection originates in Undertow as part of the HTTP upgrade, there is an external layer to the remoting connection. This connection is unaware of the outermost layer when closing the connection during the connection opening procedure. Hence, the Undertow WriteTimeoutStreamSinkConduit is not notified of the closed connection in this scenario. Because WriteTimeoutStreamSinkConduit creates a timeout task, the whole dependency tree leaks via that task, which is added to XNIO WorkerThread. So, the workerThread points to the Undertow conduit, which contains the connections and causes the leak.11dCVE-2006-3985—91.8%
——28——CVE-2014-4459—91.8%
——28——CVE-2024-41468—91.8%
——28——CVE-2024-43160—91.8%
——28——CVE-2026-462427.8 ALT91.8%
——28In the Linux kernel, the following vulnerability has been resolved:
eventpoll: fix ep_remove struct eventpoll / struct file UAF
ep_remove() (via ep_remove_file()) cleared file->f_ep under
file->f_lock but then kept using @file inside the critical section
(is_file_epoll(), hlist_del_rcu() through the head, spin_unlock).
A concurrent __fput() taking the eventpoll_release() fastpath in
that window observed the transient NULL, skipped
eventpoll_release_file() and ran to f_op->release / file_free().
For the epoll-watches-epoll case, f_op->release is
ep_eventpoll_release() -> ep_clear_and_put() -> ep_free(), which
kfree()s the watched struct eventpoll. Its embedded ->refs
hlist_head is exactly where epi->fllink.pprev points, so the
subsequent hlist_del_rcu()'s "*pprev = next" scribbles into freed
kmalloc-192 memory.
In addition, struct file is SLAB_TYPESAFE_BY_RCU, so the slot
backing @file could be recycled by alloc_empty_file() --
reinitializing f_lock and f_ep -- while ep_remove() is still
nominally inside that lock. The upshot is an attacker-controllable
kmem_cache_free() against the wrong slab cache.
Pin @file via epi_fget() at the top of ep_remove() and gate the
critical section on the pin succeeding. With the pin held @file
cannot reach refcount zero, which holds __fput() off and
transitively keeps the watched struct eventpoll alive across the
hlist_del_rcu() and the f_lock use, closing both UAFs.
If the pin fails @file has already reached refcount zero and its
__fput() is in flight. Because we bailed before clearing f_ep,
that path takes the eventpoll_release() slow path into
eventpoll_release_file() and blocks on ep->mtx until the waiter
side's ep_clear_and_put() drops it. The bailed epi's share of
ep->refcount stays intact, so the trailing ep_refcount_dec_and_test()
in ep_clear_and_put() cannot free the eventpoll out from under
eventpoll_release_file(); the orphaned epi is then cleaned up
there.
A successful pin also proves we are not racing
eventpoll_release_file() on this epi, so drop the now-redundant
re-check of epi->dying under f_lock. The cheap lockless
READ_ONCE(epi->dying) fast-path bailout stays.27dCVE-2003-0982—91.8%
——28——CVE-2021-31966—91.8%
——28——CVE-2018-20433—91.8%
——28——CVE-2014-9847—91.8%
——28——CVE-2007-1681—91.8%
——28——CVE-2018-1317—91.8%
——28——CVE-2018-16841—91.8%
——28——CVE-2019-1487—91.8%
——28——CVE-2012-1134—91.8%
——28——CVE-2001-1235—91.8%
——28——CVE-2016-2837—91.8%
——28——CVE-2015-0249—91.8%
——28——