CVE Watch352,317 in full archive

Vulnerabilities exploitable today

352,317in current view

Single score combining CVSS, KEV membership and EPSS. Every CVE with its own record — timeline from publication to active exploitation.

In KEV catalog1,653

New KEV · 24H0

Exploit Today ≥ 701,590

Distribution · last window

Critical
2,257
High
7,708
Medium
7,032
Low
663

Filters

Window

Severity

Flags

Vulnerabilities341,721–341,760 · 352,317

CVECVSSEPSSKEVRExploitTitleMod.

CVE-2026-530317.8 HIG

2.9%

——1In the Linux kernel, the following vulnerability has been resolved: bpf: Validate node_id in arena_alloc_pages() arena_alloc_pages() accepts a plain int node_id and forwards it through the entire allocation chain without any bounds checking. Validate node_id before passing it down the allocation chain in arena_alloc_pages().9d CVE-2022-32630—

2.9%

——1——CVE-2025-13987—

2.9%

——1——CVE-2026-129217.8 HIG

2.9%

——1In AzeoTech DAQFactory versions 21.1 and prior, a Use After Free vulnerability can be exploited by an attacker using specially crafted .ctl files which can result in code execution.8d CVE-2023-52713—

——1——CVE-2026-572407.8 HIG

2.9%

——1When the application opens a PDF file and JavaScript deletes the PDF fields, the subsequent logic still uses the old field pointers, resulting in invalid pointer references and causing the application to crash.16d CVE-2025-55041—

2.9%

——1——CVE-2026-622396.6 MED

2.9%

——1FlashAttention through 2.8.3.post1, fixed in commit 0816ef1, contains a symlink attack vulnerability in the download_and_copy() function within hopper/setup.py that extracts NVIDIA toolchain archives without validating symlinks or filtering tar members. A local attacker can pre-plant a symlink in the predictable cache directory to redirect extracted binaries to an attacker-chosen location, enabling arbitrary file write with victim privileges during build time.9d CVE-2026-234487.8 HIG

2.9%

——1In the Linux kernel, the following vulnerability has been resolved: net: usb: cdc_ncm: add ndpoffset to NDP16 nframes bounds check cdc_ncm_rx_verify_ndp16() validates that the NDP header and its DPE entries fit within the skb. The first check correctly accounts for ndpoffset: if ((ndpoffset + sizeof(struct usb_cdc_ncm_ndp16)) > skb_in->len) but the second check omits it: if ((sizeof(struct usb_cdc_ncm_ndp16) + ret * (sizeof(struct usb_cdc_ncm_dpe16))) > skb_in->len) This validates the DPE array size against the total skb length as if the NDP were at offset 0, rather than at ndpoffset. When the NDP is placed near the end of the NTB (large wNdpIndex), the DPE entries can extend past the skb data buffer even though the check passes. cdc_ncm_rx_fixup() then reads out-of-bounds memory when iterating the DPE array. Add ndpoffset to the nframes bounds check and use struct_size_t() to express the NDP-plus-DPE-array size more clearly.5h CVE-2026-28196—

——1——CVE-2026-315027.8 HIG

2.9%

——1In the Linux kernel, the following vulnerability has been resolved: team: fix header_ops type confusion with non-Ethernet ports Similar to commit 950803f72547 ("bonding: fix type confusion in bond_setup_by_slave()") team has the same class of header_ops type confusion. For non-Ethernet ports, team_setup_by_port() copies port_dev->header_ops directly. When the team device later calls dev_hard_header() or dev_parse_header(), these callbacks can run with the team net_device instead of the real lower device, so netdev_priv(dev) is interpreted as the wrong private type and can crash. The syzbot report shows a crash in bond_header_create(), but the root cause is in team: the topology is gre -> bond -> team, and team calls the inherited header_ops with its own net_device instead of the lower device, so bond_header_create() receives a team device and interprets netdev_priv() as bonding private data, causing a type confusion crash. Fix this by introducing team header_ops wrappers for create/parse, selecting a team port under RCU, and calling the lower device callbacks with port->dev, so each callback always sees the correct net_device context. Also pass the selected lower device to the lower parse callback, so recursion is bounded in stacked non-Ethernet topologies and parse callbacks always run with the correct device context.11h CVE-2025-71222—

——1——CVE-2026-530538.8 HIG

2.9%

——1In the Linux kernel, the following vulnerability has been resolved: iommu/amd: Fix clone_alias() to use the original device's devid Currently clone_alias() assumes first argument (pdev) is always the original device pointer. This function is called by pci_for_each_dma_alias() which based on topology decides to send original or alias device details in first argument. This meant that the source devid used to look up and copy the DTE may be incorrect, leading to wrong or stale DTE entries being propagated to alias device. Fix this by passing the original pdev as the opaque data argument to both the direct clone_alias() call and pci_for_each_dma_alias(). Inside clone_alias(), retrieve the original device from data and compute devid from it.3d CVE-2026-46084—

2.9%

——1——CVE-2026-641347.8 HIG

2.9%

——1In the Linux kernel, the following vulnerability has been resolved: ALSA: pcm: Don't setup bogus iov_iter for silencing At transition to the iov_iter for PCM data transfer, we blindly applied the iov_iter setup also for silencing (i.e. data = NULL), and it leads to a calculation of bogus iov_iter. Fortunately this didn't cause troubles on most of architectures but it goes wrong on RISC-V now, causing a NULL dereference. Handle the NULL data case to treat the silencing in interleaved_copy() for addressing the bug above. noninterleaved_copy() has already the NULL data handling, so it doesn't need changes.4d CVE-2026-31743—

2.9%

——1——CVE-2026-429587.8 HIG

2.9%

——1The application contains a use-after-free vulnerability that can be exploited to cause memory corruption while parsing specially crafted files. This could allow an attacker to execute arbitrary code in the context of the current process.15d CVE-2026-8052—

2.9%

——1——CVE-2026-529087.8 HIG

2.9%

——1In the Linux kernel, the following vulnerability has been resolved: RDMA: During rereg_mr ensure that REREG_ACCESS is compatible If IB_MR_REREG_ACCESS changes from RO to RW then the umem has to be re-evaluated to ensure it is properly pinned as RW. Since the umem is hidden inside each driver's mr struct add a ib_umem_check_rereg() function that each driver has to call before processing IB_MR_REREG_ACCESS. mlx4 has to retain its duplicate ib_access_writable check because it implements IB_MR_REREG_ACCESS | IB_MR_REREG_TRANS by changing both items in place sequentially while the MR is live, so it will continue to not support this combination.16d CVE-2025-71068—

2.9%

——1——