Export limit exceeded: 10156 CVEs match your query. Please refine your search to export 10,000 CVEs or fewer.
Search
Search Results (10156 CVEs found)
| CVE | Vendors | Products | Updated | CVSS v3.1 |
|---|---|---|---|---|
| CVE-2026-66806 | 2 Microsoft, Redhat | 7 365 Apps, Office 2019, Office 2021 and 4 more | 2026-08-14 | 5.5 Medium |
| Off-by-one error in Microsoft Office Word allows an unauthorized attacker to disclose information locally. | ||||
| CVE-2026-70310 | 1 Microsoft | 10 365 Apps, Microsoft 365, Office 2019 and 7 more | 2026-08-14 | 5.5 Medium |
| Out-of-bounds read in Microsoft Office Word allows an unauthorized attacker to disclose information locally. | ||||
| CVE-2026-61918 | 1 Microsoft | 26 Windows 10 1607, Windows 10 1809, Windows 10 21h2 and 23 more | 2026-08-14 | 6.5 Medium |
| Out-of-bounds read in Remote Desktop Client allows an unauthorized attacker to disclose information over a network. | ||||
| CVE-2026-61921 | 1 Microsoft | 26 Windows 10 1607, Windows 10 1809, Windows 10 21h2 and 23 more | 2026-08-14 | 6.5 Medium |
| Out-of-bounds read in Remote Desktop Client allows an unauthorized attacker to disclose information over a network. | ||||
| CVE-2026-62728 | 1 Microsoft | 26 Windows 10 1607, Windows 10 1809, Windows 10 21h2 and 23 more | 2026-08-14 | 7 High |
| Time-of-check time-of-use (toctou) race condition in Windows Common Log File System Driver allows an authorized attacker to elevate privileges locally. | ||||
| CVE-2026-62733 | 1 Microsoft | 26 Windows 10 1607, Windows 10 1809, Windows 10 21h2 and 23 more | 2026-08-14 | 7.8 High |
| Out-of-bounds read in Windows Win32K allows an authorized attacker to elevate privileges locally. | ||||
| CVE-2026-62743 | 1 Microsoft | 26 Windows 10 1607, Windows 10 1809, Windows 10 21h2 and 23 more | 2026-08-14 | 5.5 Medium |
| Out-of-bounds read in Windows Win32K allows an authorized attacker to disclose information locally. | ||||
| CVE-2026-62782 | 1 Microsoft | 21 Windows 10 1607, Windows 10 1809, Windows 10 21h2 and 18 more | 2026-08-14 | 6.5 Medium |
| Out-of-bounds read in Windows SMB Client allows an unauthorized attacker to disclose information over a network. | ||||
| CVE-2026-62786 | 1 Microsoft | 26 Windows 10 1607, Windows 10 1809, Windows 10 21h2 and 23 more | 2026-08-14 | 5.5 Medium |
| Out-of-bounds read in Windows Win32K allows an authorized attacker to disclose information locally. | ||||
| CVE-2026-62880 | 1 Microsoft | 26 Windows 10 1607, Windows 10 1809, Windows 10 21h2 and 23 more | 2026-08-14 | 7.8 High |
| Out-of-bounds read in Windows NTFS allows an authorized attacker to elevate privileges locally. | ||||
| CVE-2026-62887 | 1 Microsoft | 26 Windows 10 1607, Windows 10 1809, Windows 10 21h2 and 23 more | 2026-08-14 | 5.5 Medium |
| Out-of-bounds read in Windows NTFS allows an authorized attacker to disclose information locally. | ||||
| CVE-2026-62738 | 1 Microsoft | 26 Windows 10 1607, Windows 10 1809, Windows 10 21h2 and 23 more | 2026-08-14 | 5.5 Medium |
| Out-of-bounds read in Windows Management Instrumentation allows an authorized attacker to disclose information locally. | ||||
| CVE-2026-68793 | 1 Microsoft | 12 365, 365 Apps, Excel and 9 more | 2026-08-14 | 7.8 High |
| Out-of-bounds read in Microsoft Office Excel allows an unauthorized attacker to execute code locally. | ||||
| CVE-2026-55402 | 1 Absolute | 1 Secure Access | 2026-08-14 | N/A |
| CVE-2026-55402 is an out of bounds read vulnerability in Secure Access servers prior to version 14.57. Attackers with an ‘in the middle’ position can send specially crafted data to a server causing a persistent denial of service. | ||||
| CVE-2026-68125 | 1 Linux | 1 Linux Kernel | 2026-08-14 | 8.8 High |
| In the Linux kernel, the following vulnerability has been resolved: mac802154: llsec: reject frames shorter than the authentication tag llsec_do_decrypt_auth() computes the associated-data length for the AEAD request as assoclen += datalen - authlen; where datalen is the number of bytes after the MAC header and authlen (4, 8 or 16) is the length of the authentication tag. Nothing verifies that the frame actually carries at least authlen payload bytes. A secured frame whose payload is shorter than the tag makes datalen - authlen negative; assoclen is then passed to aead_request_set_ad() as an unsigned value close to 4 GiB, so crypto_aead_decrypt() walks far off the end of the scatterlist that only spans the real frame. The frame is fully attacker-controlled and reaches this path from any IEEE 802.15.4 peer in radio range. Reject frames whose payload is shorter than the authentication tag before the subtraction. Dynamically reproduced on a KASAN kernel as a general-protection-fault in the AEAD scatterwalk, and the fix confirmed. | ||||
| CVE-2026-68402 | 1 Linux | 1 Linux Kernel | 2026-08-14 | 7.1 High |
| In the Linux kernel, the following vulnerability has been resolved: wifi: cfg80211: bound element ID read when checking non-inheritance cfg80211_is_element_inherited() reads the first data octet of the candidate element (id = elem->data[0]) to look it up in an extension non-inheritance list. It does so after testing elem->id, but without verifying that the element actually has a data octet. A zero-length extension element (WLAN_EID_EXTENSION with length 0) therefore makes it read one octet past the end of the element. _ieee802_11_parse_elems_full() runs this check for every element of a frame once a non-inheritance context exists -- e.g. while parsing a per-STA profile of a Multi-Link element in a (re)association response, or a non-transmitted BSS profile -- so a crafted frame from an AP can trigger a one-octet slab-out-of-bounds read during element parsing: BUG: KASAN: slab-out-of-bounds in cfg80211_is_element_inherited Read of size 1 ... in net/wireless/scan.c Return early (treat the element as inherited) when an extension element carries no data, mirroring the existing handling of empty ID lists. The bug was found by fuzzing ieee802_11_parse_elems_full() under KASAN. | ||||
| CVE-2026-68453 | 1 Linux | 1 Linux Kernel | 2026-08-14 | 7.1 High |
| In the Linux kernel, the following vulnerability has been resolved: s390/zcrypt: Fix buffer over-read in cca_cipher2protkey Add validation of both the actual key buffer size and token length fields in all the cca_check_sec*token() functions. Additionally check in cca_gencipherkey() for possible underflow with returned key size. The CCA token structures contain user-controlled len fields that were used in operations without proper validation against both the actual buffer size and minimum token structure size. An attacker could set this field larger than the actual buffer size, leading to reading beyond buffer boundaries. This may result in a kernel crash or exposure of memory via sending this as part of a request down to the crypto card. Also an attacker could have used a very small len value and thus enforce a buffer under-run which may produce similar effects as a over-read. So now a key must - key buf length must be at least sizeof the token struct - the key len field inside the token must fit into the range of sizeof key token struct ... key buf length | ||||
| CVE-2026-68255 | 1 Linux | 1 Linux Kernel | 2026-08-14 | 7.7 High |
| In the Linux kernel, the following vulnerability has been resolved: drm/virtio: bound EDID block reads to the response buffer virtio_get_edid_block() validates the read offset only against the device-supplied resp->size field, never against the fixed-size resp->edid array. The EDID block index is driven by the device-supplied extension count, so a malicious virtio-gpu backend can advertise a large size together with a high block count and read far past the array into adjacent kernel memory, which is then surfaced in the parsed EDID (an out-of-bounds read / info leak). Also reject any read whose end exceeds the size of the edid array. Conforming EDID responses stay within the array and are unaffected. | ||||
| CVE-2026-68447 | 1 Linux | 1 Linux Kernel | 2026-08-13 | 7.1 High |
| In the Linux kernel, the following vulnerability has been resolved: drm/amdkfd: clamp v9 CRIU control stack checkpoint copy to BO size CRIU checkpoint copies the MQD control stack using cp_hqd_cntl_stack_size from hardware without bounding it to the allocated BO region. If the HW field is larger than the queue's control stack allocation, memcpy reads past the BO into adjacent GTT memory and can leak kernel data to userspace. Store the page-aligned control stack BO size in mqd_manager and clamp checkpoint copies and reported checkpoint sizes to min(cp_hqd_cntl_stack_size, mm->ctl_stack_size). Apply the same bound for multi-XCC v9.4.3 checkpoint layout. (cherry picked from commit 6c2abd0ec09e86c6323010673766f76050e28aa3) | ||||
| CVE-2026-68433 | 1 Linux | 1 Linux Kernel | 2026-08-13 | 8.6 High |
| In the Linux kernel, the following vulnerability has been resolved: libceph: bound get_version reply decode to front len handle_get_version_reply() uses msg->front_alloc_len as the decode boundary for MON_GET_VERSION_REPLY. That is the size of the reused reply buffer, not the number of bytes actually received. A truncated reply can therefore pass ceph_decode_need() and decode the second u64 from stale tail bytes left in the buffer by an earlier message, causing an uninitialized memory read. Use msg->front.iov_len as the receive-side decode boundary, matching other libceph reply handlers and limiting decoding to the bytes that were actually read from the wire. | ||||