Export limit exceeded: 10573 CVEs match your query. Please refine your search to export 10,000 CVEs or fewer.
Export limit exceeded: 28417 CVEs match your query. Please refine your search to export 10,000 CVEs or fewer.
Search
Search Results (28417 CVEs found)
| CVE | Vendors | Products | Updated | CVSS v3.1 |
|---|---|---|---|---|
| CVE-2026-111130 | 1 Openslide | 1 Openslide | 2026-10-21 | 6.1 Medium |
| OpenSlide through 4.0.1 contains a heap out-of-bounds read vulnerability in the MIRAX reader that allows attackers to read past the slide_positions array via crafted Slidedat.ini values. Attackers can supply a MIRAX slide whose CameraImageDivisionsPerSide does not evenly divide the image counts, crashing applications that open it and corrupting tile geometry. | ||||
| CVE-2026-110876 | 1 Adplug Project | 1 Adplug | 2026-10-21 | 5.5 Medium |
| AdPlug through 2.4 contains an out-of-bounds read vulnerability in src/xsm.cpp that allows attackers to read before note_table by supplying a negative note index. Attackers can craft an XSM file with the ofTAZ! signature and a song byte of 0x80 or higher, causing a global-buffer-overflow read during playback that may crash affected applications. | ||||
| CVE-2026-43858 | 1 Advantech | 1 Adam-3600 | 2026-10-20 | N/A |
| A stack-based buffer overflow vulnerability could allow a remote authenticated attacker to achieve arbitrary code execution. | ||||
| CVE-2026-113868 | 1 Mozilla | 1 Thunderbird | 2026-10-20 | 5.3 Medium |
| When authenticating to a POP3 or SMTP server using NTLM, Thunderbird did not check whether the server's challenge was valid base64. A malicious server could send a challenge that caused Thunderbird to include uninitialized heap memory in its NTLM response, disclosing that memory to the server. A challenge consisting only of base64 padding also caused an out-of-bounds read, crashing Thunderbird. This affected accounts configured to use NTLM or GSSAPI authentication. The uninitialized memory disclosure only affected NTLM. This vulnerability was fixed in Thunderbird 158.0.1 and Thunderbird 153.5.1. | ||||
| CVE-2026-88081 | 1 Microsoft | 13 Microsoft Sql Server 2017 (gdr), Microsoft Sql Server 2017 For X64-based Systems \(cu31\), Microsoft Sql Server 2019 (gdr) and 10 more | 2026-10-20 | 7.7 High |
| Out-of-bounds read in SQL Server allows an authorized attacker to disclose information over a network. | ||||
| CVE-2026-43838 | 1 Advantech | 1 Adam-3600 | 2026-10-20 | N/A |
| A stack-based buffer overflow vulnerability in the login functionality could allow an attacker to achieve code execution. | ||||
| CVE-2026-97763 | 1 Microsoft | 12 365 Apps, Microsoft 365, Microsoft Office Ltsc 2021 and 9 more | 2026-10-20 | 8.8 High |
| Heap-based buffer overflow in Microsoft Office Excel allows an unauthorized attacker to execute code over a network. | ||||
| CVE-2026-98578 | 1 Linux | 1 Linux Kernel | 2026-10-20 | 6.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: nfc: st21nfca: validate ISO15693 inventory length The ISO15693 inventory helper removes a two-byte prefix without checking that it exists, then accepts a one-byte remainder before reading data[1] as the DSFID. Require the prefix and at least two remaining bytes before copying the UID data and reading the DSFID. | ||||
| CVE-2026-91041 | 1 Eclipse | 1 Threadx Filex | 2026-10-20 | 7.8 High |
| Mounting an attacker-controlled FAT image with fault tolerance enabled causes an out-of-bounds heap write during log replay. The write is attacker-positioned and attacker-valued, and on a common embedded memory layout it reaches the FX_MEDIA driver callback, giving control of the instruction pointer. | ||||
| CVE-2026-96582 | 1 Eclipse | 1 Threadx Usbx | 2026-10-20 | 4.9 Medium |
| A HID report descriptor is a sequence of items, each declaring in its header how many data bytes follow. The USBX host walks that sequence by advancing over each header and parsing the data behind it. The walk checked that an item fitted in the descriptor only **after** it had advanced past the header and parsed the payload, and the item analysis it relied on never measured the declared sizes against the bytes actually received. A HID peripheral returning a short report descriptor therefore drove a heap out-of-bounds read during ordinary enumeration. | ||||
| CVE-2026-96406 | 1 Eclipse | 1 Threadx Usbx | 2026-10-20 | 4.9 Medium |
| A VideoStreaming interface reports the size of its whole class-specific descriptor block in the `wTotalLength` field of its input header. The USBX host recorded that figure and used it as the budget for walking the format, frame and frame-interval descriptors, without holding it against the configuration descriptor actually received. A device that reports a `wTotalLength` larger than the descriptors it supplies therefore had its own claim believed. Once the real bytes ran out the walk kept going, dereferencing the cursor past the end of the configuration buffer, in the host's context, whenever the application queried format or frame data. | ||||
| CVE-2026-96402 | 1 Eclipse | 1 Threadx Usbx | 2026-10-20 | N/A |
| A malicious USB MTP/PTP device can cause the USBX host to read past a heap buffer during ordinary object enumeration, leaking adjacent heap contents to the application or faulting on an unmapped page. | ||||
| CVE-2026-95111 | 1 Eclipse | 1 Threadx | 2026-10-20 | N/A |
| A memory-protected ThreadX module's queue request reaches the Module Manager's dispatch layer, which decides how much of the module's buffer the privileged queue copy may touch and hands that extent to the module port's range check. A queue's `tx_queue_message_size` is a count of `ULONG`s and the copy moves that many words, so the extent is `message_size * sizeof(ULONG)` bytes. The front-send dispatcher passed the word count itself. `tx_queue_send` and `tx_queue_receive`, either side of it in the same header, have always multiplied. A source buffer ending `message_size` bytes into memory the module may read was therefore accepted, and `_txe_queue_front_send` then read `message_size * sizeof(ULONG)` bytes from it in privileged mode — `3 * message_size` bytes past the end of what the module is allowed to read. The words are written into the queue's message area, so a module that can receive from that queue reads them back. | ||||
| CVE-2026-95109 | 1 Eclipse | 1 Threadx | 2026-10-20 | N/A |
| The Cortex-A7 MMU Modules port validates a caller-supplied buffer by translating **one address** — the first byte. The common Module Manager hands its range check the module instance, the start address and the complete byte size; the Cortex-A7 implementation discarded the instance and the size and asked the MMU a single question about the start. A memory-protected module therefore passed any range whose first byte was user-readable, however far the rest of it reached. Privileged dispatch code then read or wrote the whole range. Because every protected-module dispatcher that consumes a buffer or an extra-parameter array goes through this one macro, the defect is not in any individual service: it is in the primitive all of them rely on. | ||||
| CVE-2026-94023 | 1 Eclipse | 1 Threadx | 2026-10-20 | N/A |
| A ThreadX module reaches a kernel object's delete service through the Module Manager's dispatch layer, which asked one question about the pointer: does the object lie outside the module's own code and data. That is the policy for *using* an object, and using an object a module does not own is supported and intended — `txm_module_object_pointer_get_extended` searches the system's created objects by name and hands back objects the application created and objects other modules created, so that a module can send to a shared queue, take a shared semaphore or get a shared mutex. Destroying one of those is not sharing it. A module could name any object it had a pointer to and have the privileged dispatcher delete it. | ||||
| CVE-2026-102182 | 1 Juniper Networks | 1 Junos Os | 2026-10-20 | 9.8 Critical |
| A Stack-based Buffer Overflow vulnerability in the kmd component of Juniper Networks Junos OS on MX Series allows an unauthenticated network attacker to execute code as root via specific IKE certificate-based packets. This issue requires IKE to be enabled with an RSA-signature IKE policy to be vulnerable. This issue affects Junos OS on MX Series: * All versions before 21.2R3-S11; * from 21.4 before 21.4R3-S12; * from 22.2 before 22.2R3-S8; * from 22.3 before 22.3R3-S5; * from 22.4 before 22.4R3-S9; | ||||
| CVE-2026-94024 | 1 Eclipse | 1 Threadx | 2026-10-20 | N/A |
| The Module Manager's object lookup validated one byte of a memory-protected module's search name and then walked as much of it as the module declared, in privileged mode, with the kernel's preemption count raised. Both lookup dispatchers are affected: the recommended `txm_module_object_pointer_get_extended` is handed a length and does not use it to bound the buffer, and the deprecated `txm_module_object_pointer_get` supplies the largest value a `UINT` can hold, so it removes the bound rather than lacking one. A module can make the walk unbounded without knowing anything about the memory it reaches, and where the walk reaches memory a privileged read cannot take, the resulting fault leaves the kernel unable to preempt for the rest of the system's life. Vulnerable functions: `_txm_module_manager_txm_module_object_pointer_get_dispatch`, `_txm_module_manager_txm_module_object_pointer_get_extended_dispatch` (both in `common_modules/module_manager/inc/txm_module_manager_dispatch.h`) and `_txm_module_manager_object_name_compare` (`common_modules/module_manager/src/txm_module_manager_util.c`). | ||||
| CVE-2026-94202 | 1 Eclipse | 1 Threadx | 2026-10-20 | N/A |
| The Module Manager's block-pool create dispatcher proved that two `ALIGN_TYPE` words of the extra-parameter array a memory-protected module supplies lay inside the module's data, and then used indices 0 through 3 of that array. One of the two unproved words is read by the dispatcher's own buffer check, which takes index 1 as the pool start and index 2 as the length to range-check it over. So the out-of-bounds read is performed by the validation code itself, before the kernel service is reached, and the size the caller's pool start is then validated against is a word the manager has not proved the module owns. The other unproved word is read when the service's argument list is built. Vulnerable function: `_txm_module_manager_tx_block_pool_create_dispatch`, in `common_modules/module_manager/inc/txm_module_manager_dispatch.h`. | ||||
| CVE-2026-110306 | 1 Fast-uri | 1 Fast-uri | 2026-10-20 | 6.1 Medium |
| fast-uri is a dependency-free RFC 3986 URI parser and serializer for Node.js. In versions before 2.4.8, from 3.0.0 through 3.1.8, and from 4.0.0 through 4.2.2, fast-uri percent-decodes the scheme component with the legacy global unescape() function before validating it, so an input whose decoded scheme is a dangerous token is emitted as a live scheme even though RFC 3986 does not allow percent-encoding in a scheme and no other parser accepts it. An application that screens dangerous schemes on the raw input and then stores or renders the normalized or resolved result can turn an inert string into an executable javascript, data, or vbscript URL, producing a stored or reflected cross-site scripting vector, and the equal() comparison treats an encoded and a plain scheme as the same, which can bypass equality-based allowlists. The issue is fixed in fast-uri 2.4.8, 3.1.9, and 4.2.3, and users should upgrade to one of these versions or later. As a workaround, reject input whose scheme part contains a percent sign, or check the parsed scheme against an allowlist after normalization and use that same parsed result rather than the raw string. | ||||
| CVE-2026-98556 | 1 Linux | 1 Linux Kernel | 2026-10-20 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: gve: DQO: reject TSO packets with an out of range MSS gve_prep_tso() notes that the device requires the MSS to be <= 9728, but does not enforce it, assuming the 9K MTU enforced by the hypervisor and the 64KB limit on TSO sizes are enough. This does not hold for packets that were not generated locally. A guest behind a tap, or any packet socket user, can provide an arbitrary gso_size in virtio_net_hdr. Layer 2 forwarding does not check the MTU for GSO packets (is_skb_forwardable()), and gso_features_check() only bounds skb->len and gso_segs, never gso_size. Such a packet reaches gve_tx_fill_tso_ctx_desc(), which puts gso_size into the mss field of the TSO context descriptor. This field is 14 bits wide, so a gso_size of 16384 is silently turned into an MSS of zero. Drop these packets from gve_prep_tso(), and make sure that gve_features_check_dqo() leaves their GSO bits alone: skb_segment() splits at gso_size regardless of the MTU, so falling back to software segmentation would give the device non TSO packets bigger than the 9728 bytes it supports. Note that the device can still be given oversized non TSO packets when the stack segments in software for other reasons, for instance after TSO has been disabled with ethtool. This is a generic issue, because the MTU check is skipped for GSO packets in the forwarding path, and is addressed separately. | ||||