Export limit exceeded: 11037 CVEs match your query. Please refine your search to export 10,000 CVEs or fewer.
Search
Search Results (11037 CVEs found)
| CVE | Vendors | Products | Updated | CVSS v3.1 |
|---|---|---|---|---|
| CVE-2026-69494 | 1 Microsoft | 26 Windows 10 1607, Windows 10 1809, Windows 10 21h2 and 23 more | 2026-09-28 | 8.8 High |
| Out-of-bounds read in Windows Event Logging Service allows an unauthorized attacker to execute code over a network. | ||||
| CVE-2026-81884 | 2 Radare, Radareorg | 2 Radare2, Radare2 | 2026-09-28 | 2.5 Low |
| radare2 is a UNIX-like reverse engineering framework and command-line toolset. Prior to 6.2.0, radare2's Mach-O LC_DATA_IN_CODE parser was vulnerable because the Mach-O LC_DATA_IN_CODE parser trusted dataoff and datasize and allowed a final partial record to be processed. The vulnerability is triggered by opening a crafted Mach-O file while the non-default bin.verbose option is enabled. When datasize was not a multiple of data_in_code_entry, the last iteration read beyond the allocated buffer. This can cause a heap out-of-bounds read and possible process termination; no attacker-observable memory disclosure has been demonstrated. This issue is fixed in version 6.2.0. | ||||
| CVE-2026-81883 | 2 Radare, Radareorg | 2 Radare2, Radare2 | 2026-09-28 | 3.3 Low |
| radare2 is a UNIX-like reverse engineering framework and command-line toolset. Prior to 6.2.0, radare2's Lua 5.3 bytecode function parser was vulnerable because the Lua 5.3 bytecode function parser read fixed function-metadata fields immediately after a function-name string without checking the remaining buffer length. The vulnerability is triggered by opening or inspecting a crafted Lua 5.3 bytecode file whose function-name string ends at the input-buffer boundary. The parser read two integers and three one-byte fields beyond the allocated input buffer. This can cause invalid parser results or process termination; no attacker-observable memory disclosure has been demonstrated. This issue is fixed in version 6.2.0. | ||||
| CVE-2025-49796 | 1 Redhat | 15 Cert Manager, Discovery, Enterprise Linux and 12 more | 2026-09-28 | 9.1 Critical |
| A vulnerability was found in libxml2. Processing certain sch:name elements from the input XML file can trigger a memory corruption issue. This flaw allows an attacker to craft a malicious XML input file that can lead libxml to crash, resulting in a denial of service or other possible undefined behavior due to sensitive data being corrupted in memory. | ||||
| CVE-2026-68784 | 1 Microsoft | 12 Microsoft Sql Server 2017 (cu 31), Microsoft Sql Server 2017 (gdr), Microsoft Sql Server 2019 (cu 32) and 9 more | 2026-09-27 | 6.5 Medium |
| Out-of-bounds read in SQL Server allows an authorized attacker to disclose information over a network. | ||||
| CVE-2026-67633 | 1 Microsoft | 12 Microsoft Sql Server 2017 (cu 31), Microsoft Sql Server 2017 (gdr), Microsoft Sql Server 2019 (cu 32) and 9 more | 2026-09-27 | 6.5 Medium |
| Out-of-bounds read in SQL Server allows an authorized attacker to deny service over a network. | ||||
| CVE-2026-80078 | 1 Microsoft | 15 365 Apps, Microsoft 365, Microsoft 365 Apps For Enterprise and 12 more | 2026-09-27 | 6.5 Medium |
| Out-of-bounds read in Microsoft Office allows an unauthorized attacker to disclose information over a network. | ||||
| CVE-2026-88369 | 1 Zserge | 1 Jsmn | 2026-09-27 | 7.3 High |
| zserge jsmn commit 25647e6 is vulnerable to Buffer Overflow in example/jsondump.c dump(). | ||||
| CVE-2026-84549 | 1 Apple | 1 Macos | 2026-09-27 | 7.5 High |
| An out-of-bounds read was addressed with improved bounds checking. This issue is fixed in macOS Golden Gate 27, macOS Sequoia 15.8, macOS Tahoe 26.7. Connecting to a malicious NFS server may cause unexpected system termination or corrupt kernel memory. | ||||
| CVE-2026-93306 | 1 Ibm | 1 Server Firmware | 2026-09-26 | 7.1 High |
| IBM Server Firmware FW1120.00 through FW1120.01, FW1110.00 through FW1110.31, FW1060.00 through FW1060.81, and FW950.00 through FW950.H3 is affected by a vulnerability in the ASMI web interface. An unauthenticated attacker on the management network can send a malformed HTTPS request to ASMI, causing the web server to crash with possible memory corruption and generate an error log. The ASMI web interface will restart automatically; however, repeated exploitation could result in a sustained loss of access to the ASMI management interface, resulting in an integrity and availability impact. | ||||
| CVE-2026-88840 | 2 Busybox, Redhat | 3 Busybox, Hardened Images, Hummingbird | 2026-09-26 | 5.3 Medium |
| BusyBox TLS get_client_hello() reads past the end of the input buffer when parsing a truncated ClientHello message. | ||||
| CVE-2026-93682 | 2 Php Group, Redhat | 2 Php, Hummingbird | 2026-09-26 | 5.8 Medium |
| When the HTTP stream wrapper follows a redirect and the response carries a Location header with an empty value, the redirect code reads one byte past the end of the heap buffer holding the location. The value of that out-of-bounds byte decides which redirect target is built, so a malicious server controls whether the client is sent to the host root or to the current directory. | ||||
| CVE-2026-93213 | 1 Linux | 1 Linux Kernel | 2026-09-26 | N/A |
| In the Linux kernel, the following vulnerability has been resolved: of: fix out-of-bounds read in of_alias_scan() stem parser The stem parser tests isdigit(*(end - 1)) before checking end > start and so reads one byte before the property name when the name is empty or all digits. Check the bound first. | ||||
| CVE-2026-97428 | 1 Linux | 1 Linux Kernel | 2026-09-26 | 7.7 High |
| In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: harden FRU PIA parsing with bounded helpers Replace the open-coded TLV walk with fru_pia_advance() and fru_pia_copy_field() helpers that bound every read by the actual EEPROM data length, preventing out-of-bounds reads on truncated or malformed FRU data. | ||||
| CVE-2026-97433 | 1 Linux | 1 Linux Kernel | 2026-09-26 | 8.2 High |
| In the Linux kernel, the following vulnerability has been resolved: nvme: validate FDP configuration descriptor sizes Validate descriptor sizes while walking the FDP configurations log so dsze == 0 or a descriptor past the log end cannot cause unbounded iteration or reads past the buffer. | ||||
| CVE-2026-97976 | 1 Linux | 1 Linux Kernel | 2026-09-25 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: Bluetooth: btintel_pcie: validate packet_len before skb_put_data btintel_pcie_submit_rx_work() reads packet_len from rfh_hdr without checking if it exceeds the RX buffer size. An oversized packet_len can lead to an out-of-bounds read in skb_put_data(). Validate packet_len to ensure it is non-zero and does not exceed BTINTEL_PCIE_BUFFER_SIZE - sizeof(*rfh_hdr), logging an error when invalid. This issue was reported by Claude Mythos. It can be simulated either by using customized firmware configured to return an invalid packet_len or by modifying rfh_hdr->packet_len in the driver before calling btintel_pcie_submit_rx_work(). | ||||
| CVE-2026-88835 | 2 Busybox, Redhat | 3 Busybox, Hardened Images, Hummingbird | 2026-09-25 | 6.1 Medium |
| BusyBox dpkg read_package_field() steps past a NUL terminator on malformed .deb packages, causing an out-of-bounds heap read. | ||||
| CVE-2026-97915 | 1 Linux | 1 Linux Kernel | 2026-09-25 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: accel/ivpu: Limit firmware log name prints to field size The name in struct vpu_tracing_buffer_header is a fixed-size array populated by the NPU firmware. It is expected to be NUL-terminated, but nothing on the host side enforces this, so printing it with an unbounded string conversion would read past the field if the terminator is ever missing and expose adjacent bytes of the shared tracing BO through dmesg and the debugfs FW log output. Print at most as many characters as the name field holds, so the output never runs past it even if the string is not NUL-terminated. | ||||
| CVE-2026-97614 | 1 Linux | 1 Linux Kernel | 2026-09-25 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: net: dsa: tag_brcm: legacy FCS: request needed tailroom The legacy FCS tagger calculates the CRC over skb->len bytes starting at skb->data. When a nonlinear skb reaches the tagger, this reads past the linear head into unrelated slab memory. The tagger appends an Ethernet FCS but does not declare that tailroom. As a result, DSA leaves NETIF_F_SG and NETIF_F_FRAGLIST enabled on the user port, and nonlinear skbs can reach the CRC calculation. Declare the required tailroom. DSA will then clear those features and the networking core will linearize skbs before the tagger runs. A KASAN-enabled dsa_loop test using this tagger reports: BUG: KASAN: slab-out-of-bounds in crc32_le Read of size 1 at addr ffff8880397086c0 by task exp/135 Call Trace: crc32_le (lib/crc/crc32-main.c:38) brcm_leg_fcs_tag_xmit (net/dsa/tag_brcm.c:343) dsa_user_xmit (net/dsa/user.c:942) dev_hard_start_xmit (net/core/dev.c:3937) __dev_queue_xmit (net/core/dev.c:4926) packet_sendmsg (net/packet/af_packet.c:3110) __sys_sendto (net/socket.c:2281) The buggy address belongs to the object at ffff888039708400 which belongs to the cache skbuff_small_head of size 704 The buggy address is located 0 bytes to the right of allocated 704-byte region [ffff888039708400, ffff8880397086c0) | ||||
| CVE-2026-98149 | 1 Linux | 1 Linux Kernel | 2026-09-25 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: bpf: Fix percpu map update indexing with sparse CPU IDs Per-CPU array, hash, and cgroup storage map updates without BPF_F_CPU or BPF_F_ALL_CPUS use a value buffer whose per-CPU slots are packed in possible-CPU order. The buffer is sized as: round_up(value_size, 8) * num_possible_cpus() The update paths iterate over possible CPUs, but use the logical CPU ID to calculate the source offset: value + size * cpu This only works when possible CPU IDs are contiguous starting at zero. For example, with a possible CPU mask of 0,2-3, the buffer contains three slots corresponding to CPUs 0, 2, and 3. CPU2 is therefore expected to use slot 1 and CPU3 slot 2. Instead, the current code uses slots 2 and 3 respectively, causing incorrect per-CPU values and an out-of-bounds read from the update buffer for CPU3. The corresponding lookup paths already use a dense offset while iterating over possible CPUs. Do the same for the array, hash, and cgroup storage update paths, advancing the source offset once for each possible CPU. BPF_F_ALL_CPUS continues to use the same value for every CPU. | ||||