CVE Watch406,215 en archivo total

Vulnerabilidades explotables hoy

406,215en 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,766

Nuevos KEV · 24H0

Exploit Today ≥ 701,698

Distribución · última ventana

Crítico
5,576
Alto
21,709
Medio
20,212
Bajo
2,100

Filtros

Ventana

Severidad

Filtros

Vulnerabilidades396,641–396,680 · 406,215

CVECVSSEPSSKEVRExplotTítuloVis.

CVE-2026-41360—

0.4%

——0——CVE-2026-816455.9 MED

0.4%

——0Out-of-bounds read vulnerability in the graphics module. Successful exploitation of this vulnerability may affect availability.37d CVE-2025-13437—

0.4%

——0When zx is invoked with --prefer-local=<path>, the CLI creates a symlink named ./node_modules pointing to <path>/node_modules. Due to a logic error in src/cli.ts (linkNodeModules / cleanup), the function returns the target path instead of the alias (symlink path). The later cleanup routine removes what it received, which deletes the target directory itself. Result: zx can delete an external <path>/node_modules outside the current working directory.13d CVE-2022-48247—

0.4%

——0——CVE-2023-20703—

0.4%

——0——CVE-2026-440723.0 BAJ

0.4%

——0Netatalk 2.2.1 through 4.4.2 calls system() after a failed chdir() without properly handling the error condition, which allows a local privileged user to execute unintended commands or cause a minor service disruption under specific conditions.100d CVE-2023-21308—

0.4%

——0——CVE-2026-1183733.7 BAJ

0.4%

——0LibreSSL ocspcheck through 4.4.0 contains a cleartext transmission vulnerability because url2host() discards the OCSP URL scheme and http_alloc() only selects TLS for port 443. On-path network attackers can read OCSP requests sent to https responder URLs on non-443 ports, exposing certificate serial numbers, issuer hashes, and nonces.3d CVE-2026-353646.3 MED

0.4%

——0A Time-of-Check to Time-of-Use (TOCTOU) race condition exists in the mv utility of uutils coreutils during cross-device operations. The utility removes the destination path before recreating it through a copy operation. A local attacker with write access to the destination directory can exploit this window to replace the destination with a symbolic link. The subsequent privileged move operation will follow the symlink, allowing the attacker to redirect the write and overwrite an arbitrary target file with contents from the source.5d CVE-2024-20029—

——0——CVE-2026-419605.8 MED

0.4%

——0Permission control vulnerability in calls. Impact: Successful exploitation of this vulnerability may affect availability.5d CVE-2023-20705—

——0——CVE-2026-353574.7 MED

0.4%

——0The cp utility in uutils coreutils is vulnerable to an information disclosure race condition. Destination files are initially created with umask-derived permissions (e.g., 0644) before being restricted to their final mode (e.g., 0600) later in the process. A local attacker can race to open the file during this window; once obtained, the file descriptor remains valid and readable even after the permissions are tightened, exposing sensitive or private file contents.5d CVE-2025-485595.5 MED

0.4%

——0In multiple functions of AppOpsService.java, there is a possible add a large amount of app ops due to improper input validation. This could lead to local denial of service with no additional execution privileges needed. User interaction is not needed for exploitation.31d CVE-2025-54645—

——0——CVE-2026-963953.6 BAJ

0.4%

——0The Affinity by Canva app for macOS before 3.3.1 (October 2026 release) did not perform adequate bounds checking when generating QuickLook thumbnails and previews of Affinity document files, leading to an out-of-bounds heap read. A threat actor could craft an Affinity document that, when displayed or previewed by a user in Finder, could disclose the contents of adjacent heap memory, including memory addresses, in the rendered thumbnail or preview image.22d CVE-2022-38676—

——0——CVE-2026-980994.7 MED

0.4%

——0In the Linux kernel, the following vulnerability has been resolved: ipv6: mcast: use rcu_assign_pointer() for __rcu list updates Several places in net/ipv6/mcast.c update RCU-protected lists (np->ipv6_mc_list, idev->mc_list, idev->mc_tomb) using direct pointer assignments instead of rcu_assign_pointer(): 1. In __ipv6_dev_mc_dec(), unlinking a group from idev->mc_list did: *map = ma->next; without rcu_assign_pointer() while concurrent readers traverse idev->mc_list locklessly under rcu_read_lock(). 2. In ipv6_sock_mc_drop() and __ipv6_sock_mc_close(), unlinking a group from np->ipv6_mc_list directly assigned *lnk = mc_lst->next and np->ipv6_mc_list = mc_lst->next without rcu_assign_pointer(), racing with lockless readers in inet6_mc_check(). 3. In __ipv6_sock_mc_join(), mc_lst->next was initialized to np->ipv6_mc_list via raw assignment before publishing mc_lst. 4. In mld_del_delrec() and __ipv6_dev_mc_inc(), __rcu source pointers passed into rcu_assign_pointer() lacked explicit dereference helpers. Fix these by consistently using rcu_assign_pointer() along with mc_dereference() / sock_dereference().3d CVE-2025-485947.3 ALT

0.4%

——0In onUidImportance of DisassociationProcessor.java, there is a possible way to retain companion application privileges after disassociation due to improper input validation. This could lead to local escalation of privilege with no additional execution privileges needed. User interaction is needed for exploitation.24d CVE-2026-981187.1 ALT

0.4%

——0In the Linux kernel, the following vulnerability has been resolved: netfs: Fix readahead synchronisation issues by loading all folios upfront There are some synchronisation issues that derive from the app thread adding more folios to the rolling buffer whilst the collector thread is looking at them or trying to clear them, such as determining the setting of front_folio_order when the next folio hasn't been added yet, The reason for the rolling buffer approach is that loading the buffer upfront and then dropping all the refs just acquired is quite a slow operation, and loading progressively allows some of the cost to be deferred until after at least some of the I/O is started. Instead, a better way is to load all the folios into the rolling buffer upfront - and then drop the refs later, once the I/O is in progress. (Even better would be for the refs not to be there at all.) Fix this by changing the rolling buffer loader to load all the folios selected by the VM for readahead upfront into the folio queue. The folio queue is allocated a batch worth at a time as we don't know how many folios are involved (the readahead_control struct, alas, has a page count, not a folio count). The folio refs acquired from readahead are then dropped in bulk once the first subrequest is dispatched as it's quite a slow operation. The collector waits for NETFS_RREQ_NEED_PUT_RA_REFS to be cleared so that it doesn't unlock folios before the xarray has been scanned for them. This simplifies the buffer handling later and isn't noticeably slower as the xarray doesn't need to be modified and the folios are all already pre-locked.3d CVE-2026-555954.7 MED

0.4%

——0ImageMagick is free and open-source software used for editing and manipulating digital images. Prior to versions 6.9.13-51 and 7.1.2-26, when providing invalid arguments to the connected-components option an infinite loop will occur. This issue has been fixed in versions 6.9.13-51 and 7.1.2-26.121d CVE-2025-327475.3 MED

0.4%

——0Dell PowerFlex Manager, version(s) <=4.6.2, contain(s) an Incorrect Privilege Assignment vulnerability. A low privileged attacker with local access could potentially exploit this vulnerability, leading to Elevation of privileges.26d