Export limit exceeded: 398412 CVEs match your query. Please refine your search to export 10,000 CVEs or fewer.
Search
Search Results (26470 CVEs found)
| CVE | Vendors | Products | Updated | CVSS v3.1 |
|---|---|---|---|---|
| CVE-2026-68797 | 1 Microsoft | 11 365 Apps, Excel, Excel 2016 and 8 more | 2026-08-13 | 5.5 Medium |
| Out-of-bounds read in Microsoft Office Excel allows an unauthorized attacker to disclose information locally. | ||||
| CVE-2026-70328 | 1 Microsoft | 10 365 Apps, Excel, Excel 2016 and 7 more | 2026-08-13 | 6.5 Medium |
| Out-of-bounds read in Microsoft Office Excel allows an unauthorized attacker to disclose information over a network. | ||||
| CVE-2026-70327 | 1 Microsoft | 10 365 Apps, Excel, Excel 2016 and 7 more | 2026-08-13 | 6.5 Medium |
| Out-of-bounds read in Microsoft Office Excel allows an unauthorized attacker to disclose information over a network. | ||||
| CVE-2026-68816 | 1 Microsoft | 10 365 Apps, Excel, Excel 2016 and 7 more | 2026-08-13 | 7.8 High |
| Stack-based buffer overflow in Microsoft Office Excel allows an unauthorized attacker to execute code locally. | ||||
| CVE-2026-68808 | 1 Microsoft | 14 365 Apps, Excel, Excel 2016 and 11 more | 2026-08-13 | 5.5 Medium |
| Out-of-bounds read in Microsoft Office Excel allows an unauthorized attacker to disclose information locally. | ||||
| CVE-2026-68802 | 1 Microsoft | 10 365 Apps, Excel, Excel 2016 and 7 more | 2026-08-13 | 5.5 Medium |
| Out-of-bounds read in Microsoft Office Excel allows an unauthorized attacker to disclose information locally. | ||||
| CVE-2026-68796 | 1 Microsoft | 11 365, 365 Apps, Excel and 8 more | 2026-08-13 | 7.8 High |
| Heap-based buffer overflow in Microsoft Office Excel allows an unauthorized attacker to execute code locally. | ||||
| CVE-2026-68795 | 1 Microsoft | 13 365 Apps, Excel, Excel 2016 and 10 more | 2026-08-13 | 7.8 High |
| Stack-based buffer overflow in Microsoft Office Excel allows an unauthorized attacker to execute code locally. | ||||
| CVE-2026-68794 | 1 Microsoft | 10 365 Apps, Excel, Excel 2016 and 7 more | 2026-08-13 | 7.8 High |
| Heap-based buffer overflow in Microsoft Office Excel allows an unauthorized attacker to execute code locally. | ||||
| CVE-2026-62772 | 1 Microsoft | 2 Windows 11 26h1, Windows 11 26h1 | 2026-08-13 | 7.8 High |
| Heap-based buffer overflow in Windows Container Isolation FS Filter Driver (unionfs.sys) allows an authorized attacker to elevate privileges locally. | ||||
| CVE-2026-64167 | 1 Linux | 1 Linux Kernel | 2026-08-13 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: kho: skip KHO for crash kernel kho_fill_kimage() unconditionally populates the kimage with KHO metadata for every kexec image type. When the image is a crash kernel, this can be problematic as the crash kernel can run in a small reserved region and the KHO scratch areas can sit outside it. The crash kernel then faults during kho_memory_init() when it tries phys_to_virt() on the KHO FDT address: Unable to handle kernel paging request at virtual address xxxxxxxx ... fdt_offset_ptr+... fdt_check_node_offset_+... fdt_first_property_offset+... fdt_get_property_namelen_+... fdt_getprop+... kho_memory_init+... mm_core_init+... start_kernel+... kho_locate_mem_hole() already skips KHO logic for KEXEC_TYPE_CRASH images, but kho_fill_kimage() was missing the same guard. As kho_fill_kimage() is the single point that populates image->kho.fdt and image->kho.scratch, fixing it here is sufficient for both arm64 and x86 as the FDT and boot_params path are bailing out when these fields are unset. | ||||
| CVE-2026-73491 | 1 Flavorjones | 1 Loofah | 2026-08-13 | 3.7 Low |
| Loofah is a general library for manipulating and transforming HTML/XML documents and fragments, built on top of Nokogiri. From 2.25.0 until 2.25.2, Loofah::HTML5::Scrub.allowed_uri? does not reject javascript: URIs whose scheme is split or prefixed with the HTML5 named whitespace character references 	 or 
. CGI.unescapeHTML leaves those references intact, so allowed_uri? reports the URL safe even though a browser decodes and strips the tab or line feed and executes the resulting javascript: URL. This issue affects only callers that pass HTML-encoded strings directly to allowed_uri?; Loofah's default sanitize() path is not affected. This issue is fixed in version 2.25.2. | ||||
| CVE-2026-72522 | 1 Libexpat Project | 1 Libexpat | 2026-08-13 | 6.2 Medium |
| libexpat before 2.8.3 has an out-of-bounds read and resultant infinite loop because low surrogates are treated the same as high surrogates during Unicode processing in the *_toUtf16 functions. | ||||
| CVE-2026-18368 | 1 Teltonika-networks | 1 Rutos | 2026-08-13 | N/A |
| In Teltonika Networks RUTOS devices, a vulnerability exists in modbusgwd due to improper handling of Modbus TCP request data. A remote, unauthenticated attacker with access to the affected service could trigger a heap-based buffer overflow, resulting in a denial of service. | ||||
| CVE-2026-64287 | 1 Linux | 1 Linux Kernel | 2026-08-13 | 8.2 High |
| In the Linux kernel, the following vulnerability has been resolved: KVM: arm64: Bound used_lrs when flushing the pKVM hyp vCPU flush_hyp_vcpu() copies the host vGIC state into the hyp's private vCPU on every run. The vGIC list register save and restore use used_lrs as their loop bound and expect it to stay within the number of implemented list registers. While this is generally the case, flush_hyp_vcpu() copies vgic_v3 verbatim and does not enforce this, so a value provided by the host is used at EL2 to index vgic_lr[] and access ICH_LR<n>_EL2 (host -> EL2). Fix by clamping used_lrs to the number of implemented list registers after the copy, as the trusted path already does in vgic_flush_lr_state(). The number of implemented list registers is constant after init, so it is replicated once from kvm_vgic_global_state.nr_lr into hyp_gicv3_nr_lr rather than read on every entry. | ||||
| CVE-2026-64121 | 1 Linux | 1 Linux Kernel | 2026-08-13 | 7.1 High |
| In the Linux kernel, the following vulnerability has been resolved: net: ifb: report ethtool stats over num_tx_queues ifb_dev_init() allocates dp->tx_private to dev->num_tx_queues entries via kzalloc_objs(*txp, dev->num_tx_queues). Both IFB per-queue RX and TX stats live in those entries: ifb_xmit() updates txp->rx_stats using the skb queue mapping, ifb_ri_tasklet() updates txp->tx_stats, and ifb_stats64() aggregates both over dev->num_tx_queues. The ethtool stats callbacks instead size and walk the per-queue stats with dev->real_num_rx_queues and dev->real_num_tx_queues. With an asymmetric device where the RX queue count exceeds the TX queue count, for example: ip link add name ifb10 numtxqueues 1 numrxqueues 8 type ifb ethtool -S ifb10 ifb_get_ethtool_stats() indexes past the tx_private allocation and copies adjacent slab data through ETHTOOL_GSTATS. Use dev->num_tx_queues consistently for the stats strings, the stats count, and the stats data walks. This reports one RX stats group and one TX stats group for each backing ifb_q_private entry, which is the queue set IFB can actually populate. Reproduced under UML+KASAN at v7.1-rc2: BUG: KASAN: slab-out-of-bounds in ifb_fill_stats_data+0x3c/0xae Read of size 8 at addr 0000000062dbd228 by task ethtool/36 ifb_fill_stats_data+0x3c/0xae ifb_get_ethtool_stats+0xc0/0x129 __dev_ethtool+0x1ca5/0x363c dev_ethtool+0x123/0x1b3 dev_ioctl+0x56c/0x744 sock_do_ioctl+0x15f/0x1b2 sock_ioctl+0x4d5/0x50a sys_ioctl+0xd8b/0xde9 With the patch applied, the same UML+KASAN repro is silent and ethtool -S ifb10 reports only the stats backed by the single allocated tx_private entry. | ||||
| CVE-2026-64124 | 1 Linux | 1 Linux Kernel | 2026-08-13 | 8.8 High |
| In the Linux kernel, the following vulnerability has been resolved: net: devmem: reject dma-buf bind with non-page-aligned size or SG length net_devmem_bind_dmabuf() trusts dmabuf->size and sg_dma_len() to be PAGE_SIZE multiples without checking: - tx_vec is sized dmabuf->size / PAGE_SIZE, and net_devmem_get_niov_at() only bounds-checks virt_addr < dmabuf->size before indexing tx_vec[virt_addr / PAGE_SIZE]. With size = N*PAGE_SIZE + r (1 <= r < PAGE_SIZE), sendmsg() at iov_base = N*PAGE_SIZE passes the bound check and reads tx_vec[N] -- one past. - owner->area.num_niovs = len / PAGE_SIZE while gen_pool_add_owner() covers the full byte len, so a non-page-multiple non-final sg desyncs num_niovs from the gen_pool region for every later sg, on both RX and TX. dma-buf does not require page-aligned sizes, so the bind path has to enforce what its own indexing assumes. Reject both with -EINVAL. The size check is TX-only (only tx_vec is sized off dmabuf->size); the SG-length check covers both directions. | ||||
| CVE-2026-64126 | 1 Linux | 1 Linux Kernel | 2026-08-13 | 7.3 High |
| In the Linux kernel, the following vulnerability has been resolved: Bluetooth: MGMT: validate Add Extended Advertising Data length MGMT_OP_ADD_EXT_ADV_DATA is registered as a variable-length command, with MGMT_ADD_EXT_ADV_DATA_SIZE as the fixed header size. The handler then uses cp->adv_data_len and cp->scan_rsp_len to validate and copy cp->data, but it never checks that those bytes are part of the mgmt command payload. A short command can therefore make add_ext_adv_data() pass an out-of-bounds pointer into tlv_data_is_valid(). If the bytes beyond the command buffer are addressable, they can also be copied into the advertising instance as scan response data, where the caller can read them back via MGMT_OP_GET_ADV_INSTANCE. The trigger requires CAP_NET_ADMIN in the initial user namespace; KASAN reports an 8-byte slab-out-of-bounds read. Reject commands whose length does not match the fixed header plus both advertising data lengths before parsing cp->data. | ||||
| CVE-2026-64133 | 1 Linux | 1 Linux Kernel | 2026-08-13 | 7.8 High |
| In the Linux kernel, the following vulnerability has been resolved: ALSA: asihpi: Fix potential OOB array access at reading cache find_control() to retrieve a cached info accesses the array with the given index blindly, which may lead to an OOB array access. Add a sanity check for avoiding it. | ||||
| CVE-2026-64135 | 1 Linux | 1 Linux Kernel | 2026-08-13 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: hwmon: (pmbus/adm1266) widen blackbox-info buffer to I2C_SMBUS_BLOCK_MAX adm1266_nvmem_read_blackbox() declares a 5-byte stack buffer and passes it to i2c_smbus_read_block_data() to retrieve the 4-byte BLACKBOX_INFO response. i2c_smbus_read_block_data() does not honour caller buffer sizes -- it memcpy()s data.block[0] bytes from the SMBus transaction (where data.block[0] is the length byte returned by the slave device, up to I2C_SMBUS_BLOCK_MAX = 32): memcpy(values, &data.block[1], data.block[0]); If the device returns any block length above 5, the call overflows the caller's 5-byte stack buffer before the post-call if (ret != 4) return -EIO; check has a chance to reject the response. Widen the local buffer to I2C_SMBUS_BLOCK_MAX so the helper has room for any well-formed SMBus block response, matching the convention used by the other i2c_smbus_read_block_data() callers in this driver. | ||||