Export limit exceeded: 26377 CVEs match your query. Please refine your search to export 10,000 CVEs or fewer.
Search
Search Results (26377 CVEs found)
| CVE | Vendors | Products | Updated | CVSS v3.1 |
|---|---|---|---|---|
| CVE-2026-53938 | 1 Openidc | 1 Cjose | 2026-09-13 | 8.2 High |
| OpenIDC/cjose is a C library implementing the Javascript Object Signing and Encryption (JOSE). Prior to version 0.6.2.5, cjose's JWE decryption path for the AES Key Wrap key-management algorithms (`alg` = `A128KW`, `A192KW`, `A256KW`) does not validate the length of the attacker-supplied `encrypted_key` (JWE Encrypted Key) before unwrapping it into a fixed-size, heap-allocated Content Encryption Key (CEK) buffer. A remote, unauthenticated attacker who can submit a crafted JWE to an application that decrypts it with an AES-KW symmetric key can trigger an out-of-bounds heap write, corrupting the heap. This leads at minimum to a crash (denial of service) and, depending on the heap layout and allocator, may be leverageable for further memory-corruption impact. `cjose_jwe_import()` / `cjose_jwe_decrypt()` are pre-authentication entry points: they parse and process fully attacker-controlled input. Upgrade to cjose 0.6.2.5 to receive a patch. If upgrading is not immediately possible, reject the AES Key Wrap algorithms (`A128KW`/`A192KW`/`A256KW`) for untrusted JWEs at the application layer. | ||||
| CVE-2026-42804 | 1 Bosch Sensortec | 1 Bhi360 Sensorapi (c-library) | 2026-09-13 | 7.6 High |
| A stack-based buffer overflow vulnerability exists in the Bosch Sensortec BHI360 SensorAPI(C-Library) in versions up to and including commit d6b200416a. The vulnerability is located within the FIFO parsing and debug logging subsystem inside the function bhi360_parse_debug_message() in bhi360_parse.c (lines 1852-1875). The parser trusts the first payload byte of a debug frame as the message length (msg_length) and copies that many bytes into a fixed-size 17-byte stack buffer (debug_msg) via memcpy without performing any bounds checking. A locally or physically positioned attacker (e.g., via a malicious sensor, counterfeit hardware module, or a Man-in-the-Middle on the communication bus) can exploit this vulnerability by injecting a crafted debug frame with a length byte exceeding 16. This corrupts adjacent stack data, including the saved return address. Furthermore, because the overflowed buffer is subsequently passed to a printf-style logging sink, the attacker can supply format string specifiers (e.g., %n) to execute arbitrary code on the host microcontroller/SoC or cause a reliable system crash (Denial of Service). | ||||
| CVE-2026-42805 | 1 Bosch Sensortec | 1 Bhi385 Sensorapi (c Library) | 2026-09-13 | 8.4 High |
| A stack-based buffer overflow vulnerability exists in the Bosch Sensortec BHI385 SensorAPI (C library) within the debug message parser function bhi385_parse_debug_message (located in bhi385_parse.c). The function parses FIFO events and extracts an 8-bit message length directly from the attacker-controlled event payload (callback_info->data_ptr[0]) without enforcing bounds checks or clamping the value. When copying the payload into a fixed-size stack buffer of 17 bytes (uint8_t debug_msg[17]) via memcpy, providing a length byte greater than 16 causes the function to write past the allocated stack boundary. This memory corruption can be triggered by a malicious or compromised sensor or bus participant, leading to a firmware crash, Denial of Service (DoS), or potentially the execution of arbitrary code via adjacent stack data corruption. | ||||
| CVE-2026-42806 | 1 Bosch Sensortec | 1 Bme690 Sensorapi (c) | 2026-09-13 | 4.3 Medium |
| An out-of-bounds read vulnerability was discovered in the Bosch BME690 SensorAPI (C-driver) in version v1.0.3 and prior, specifically within the field data parsing logic in read_all_field_data (bme69x.c). The driver prefetches heater configuration registers into a contiguous 30-byte stack buffer (set_val) mapping IDAC, RES_HEAT, and GAS_WAIT tables. When parsing sensor field data, the gas_index is extracted using a 4-bit mask (0..15) but lacks boundary verification against the valid range (0..9). An attacker or a compromised peripheral mimicking a sensor on the I2C/SPI bus could return a payload with a gas index value of 10 or higher. This causes the driver to perform an out-of-bounds array access (set_val[20 + gas_index]), reading up to 6 bytes past the stack buffer. The leaked out-of-bounds byte is then written into the public gas_wait field, which may lead to measurement corruption or leak adjacent stack memory when telemetered or logged. | ||||
| CVE-2026-42807 | 1 Bosch Sensortec | 1 Coines Sdk | 2026-09-13 | 8 High |
| A heap-based buffer overflow vulnerability in the PC bridge protocol decoder of BoschSensortec COINES_SDK (versions 2.10 through 2.12.2) allows attackers to cause a denial of service (process crash) or potentially execute arbitrary code. The bridge decoder ({{bridge_decoder.c}}) trusts the packet length field provided by the external device and forwards it to the host response queue ({{mqueue_add_data}}) without validating the bounds of the destination buffer. A malicious or compromised USB or Bluetooth Low Energy (BLE) peripheral can advertise a payload size up to ~3 KB, which exceeds the default queue slot size of 255 bytes. This results in an unbounded heap overwrite ({{memcpy}}), corrupting adjacent heap metadata on the host system when processing the device's response. | ||||
| CVE-2026-42808 | 1 Bosch Sensortec | 1 Coines Sdk | 2026-09-13 | 6.8 Medium |
| An issue was discovered in Bosch Sensortec COINES_SDK versions 2.0 through 2.11. The host streaming API function {{coines_read_stream_sensor_data()}} fails to validate the boundaries of the caller-provided destination buffer. Internally, the stream processing mechanism in {{comm_intf_process_stream_response()}} discards the requested {{number_of_samples}} argument and copies the entirety of the streaming ring buffer's accumulated data into {{coines_stream_rsp_buf}}. Subsequently, {{coines_read_stream_sensor_data()}} unconditionally executes a {{memcpy}} of the ring buffer size into the caller-provided buffer without verifying if the destination memory allocation is large enough. A malicious or compromised hardware board connected via USB or BLE can exploit this by streaming a high volume of sensor samples, causing a heap or stack-based buffer overflow on the host desktop environment. This can result in a Denial of Service (DoS) or potential arbitrary code execution on the host machine. | ||||
| CVE-2026-15419 | 1 Silicon Labs | 1 Silabser.sys Driver | 2026-09-13 | N/A |
| In the silabser.sys driver for CP210x devices v11.5.0 and earlier, a local unprivileged user with a malicious device can use malformed packets to corrupt kernel pool memory, resulting in arbitrary code execution with escalated privileges. | ||||
| CVE-2026-76653 | 1 Tp-link | 2 Archer Mr600, Tl-mr6400 V8 | 2026-09-13 | N/A |
| A missing authentication vulnerability in the VPN configuration management has been identified in Archer MR600 (v2, v3 & v5) and TL-MR6400 v8 due to improper access control; a remote unauthenticated attacker may be able to access and modify VPN configuration information without valid credentials. Successful exploitation may allow a remote unauthenticated attacker to disclose and modify VPN configuration information. | ||||
| CVE-2026-16172 | 1 Netskope | 1 Endpoint Dlp | 2026-09-13 | N/A |
| Netskope was notified of an out-of-bounds heap read affecting the Endpoint DLP (EPDLP) service of the Netskope Client. A local standard user could potentially send a specially crafted message that is not properly validated with a bounds check, likely crashing the kernel driver handler. Successful exploitation could potentially crash the EPDLP service, temporarily interrupting DLP enforcement. A successful exploit could potentially also reveal per-boot memory layout information to unauthorized users. | ||||
| CVE-2026-88260 | 1 Brainzcompany | 1 Zenius Ems 8.0 | 2026-09-13 | N/A |
| Authentication bypass using an alternate path or channel and Improper validation of syntactic correctness of input vulnerability in Brainzcompany Zenius EMS 8.0 allows Remote Code Inclusion. This issue affects Zenius EMS 8.0: through OAM (Build 109). | ||||
| CVE-2026-78546 | 1 Citirx | 1 Workspace App For Windows | 2026-09-13 | N/A |
| Out-of-bounds read vulnerability in Citirx Workspace app for Windows. This issue affects Workspace app for Windows: before 2603.11 Current Release (CR), before 2507.1 LTSR CU3, and before LTSR 2607. | ||||
| CVE-2026-88284 | 1 Geovision Inc. | 2 Gv-lpc2011 Lpc2211, Gv-lpc2011 Lpc2211 - | 2026-09-13 | 4.9 Medium |
| GeoVision GV-LPC2211 V1.13 fails to limit repeated User elements in ONVIF SetUser requests, allowing an authenticated administrator to overwrite stack control state and crash the ONVIF worker. | ||||
| CVE-2026-80087 | 1 Microsoft | 11 365, 365 Apps, Microsoft 365 and 8 more | 2026-09-13 | 6.5 Medium |
| Heap-based buffer overflow in Microsoft Office allows an unauthorized attacker to disclose information over a network. | ||||
| CVE-2026-80088 | 1 Microsoft | 17 365 Apps, Microsoft 365, Microsoft 365 Apps For Enterprise and 14 more | 2026-09-13 | 6.5 Medium |
| Out-of-bounds read in Microsoft Office Word allows an unauthorized attacker to disclose information over a network. | ||||
| CVE-2026-89743 | 1 Linux | 1 Linux Kernel | 2026-09-13 | 7.7 High |
| In the Linux kernel, the following vulnerability has been resolved: misc: nsm: bound the device-reported response length nsm_sendrecv_msg_locked() stores the virtqueue used-ring length reported by the NSM device into msg->resp.len without bounding it to the response buffer. A malicious or buggy backend can report a length larger than the response buffer; parse_resp_raw() then copies that many bytes out of the fixed buffer to user space, disclosing adjacent kernel heap (an out-of-bounds read). The request path already floors its length in fill_req_raw(); the response path lacks the symmetric check. Clamp the stored length to the size of the response buffer. Well-behaved devices report no more than the posted buffer size, so conforming traffic is unaffected. | ||||
| CVE-2026-89705 | 1 Linux | 1 Linux Kernel | 2026-09-13 | 7.1 High |
| In the Linux kernel, the following vulnerability has been resolved: nfsd: restore rq_status_counter to even on all nfsd_dispatch() exit paths nfsd_dispatch() sets rq_status_counter to an odd value once a request has been decoded, and back to an even value once it has been fully processed, forming a seq-lock like protocol with the lockless reader in nfsd_nl_rpc_status_get_dumpit(). Only the fully successful path restored the counter to even. The cache-hit (RC_REPLY), drop (RC_DROPIT / RQ_DROPME) and encode-error paths all return after the odd-valued store without ever bringing the counter back to even. Once one of those paths is taken, rq_status_counter is left odd: the next request's decode ORs in 1 (still odd) and only a subsequent successful encode restores even. While stuck odd, the dumpit reader treats the rqstp fields as stable and its retry check compares against the same unchanging odd value, so it never detects concurrent mutation. This exposes actively mutating fields (e.g. args->ops / args->opcnt during compound decode and release) to the lockless reader, which can read past the end of the 8-element inline ops array. Add a helper that advances the counter to the next even value and call it on every return path that follows the odd-valued store. The decode-error path is left untouched as it is reached before the counter is set odd. | ||||
| CVE-2026-89691 | 1 Linux | 1 Linux Kernel | 2026-09-13 | 7.1 High |
| In the Linux kernel, the following vulnerability has been resolved: nfsd: clear opcnt on compound arg release to prevent OOB read nfsd4_release_compoundargs() resets args->ops to the inline iops[8] array when the dynamically-allocated ops buffer is freed, but leaves args->opcnt at its original value (which can be up to 200 for NFSv4.1+ compounds). If rq_status_counter is stuck at an odd value (which can happen when nfsd_dispatch() hits an error path after setting it odd), the RPC status dumpit handler reads min(opcnt, 16) entries from args->ops[]. Since iops only has 8 elements and is the last field in struct nfsd4_compoundargs, reading indices 8-15 accesses adjacent slab memory and leaks it to userspace via netlink. Zero opcnt unconditionally in nfsd4_release_compoundargs() so stale compound metadata is never exposed through the status interface. [ cel: Remove the kvfree_rcu_mightsleep() sleep from the exposure window ] | ||||
| CVE-2026-89651 | 1 Linux | 1 Linux Kernel | 2026-09-13 | 9.8 Critical |
| In the Linux kernel, the following vulnerability has been resolved: ceph: bound MDSCapAuth path and fs_name decode in handle_session() handle_session() decodes the MDSCapAuth records carried by a CEPH_SESSION_OPEN message (msg_version >= 6). For each record the match.path and match.fs_name byte strings are read by first decoding a 32-bit length and then copying that many bytes with the bare ceph_decode_copy(). Unlike the surrounding fields, which all use the _safe decode variants, these two copies are not preceded by a ceph_decode_need() bounds check, and the enclosing MDSCapAuth and MDSCapMatch struct_len fields are skipped rather than enforced as an upper bound. A length larger than the bytes remaining in the message front makes ceph_decode_copy() read past the end of the front buffer. The message front is a dedicated allocation (ceph_msg_new2() -> kvmalloc), so the over-read runs off that object. A malicious or compromised MDS can trigger this with the first post-connect message on mount, with no client-side user interaction; under KASAN it is reported as a slab-out-of-bounds read in handle_session(). Impact: a malicious MDS can force the kernel client to read up to 4 GiB past the message front allocation during session setup, crashing the client (out-of-bounds read). Switch both copies to ceph_decode_copy_safe(), which performs the ceph_decode_need() bounds check before the copy and branches to the existing bad label, matching the rest of the decoder and the error path that frees the partially decoded cap_auths array. | ||||
| CVE-2026-89633 | 1 Linux | 1 Linux Kernel | 2026-09-13 | 9.8 Critical |
| In the Linux kernel, the following vulnerability has been resolved: smb: client: fix OOB read/write from unvalidated DataOffset in coalesce_t2() coalesce_t2() computes data pointers directly from server-supplied DataOffset fields with no validation against buffer bounds: data_area_of_tgt = (char *)&pSMBt->hdr.Protocol + get_unaligned_le16(&pSMBt->t2_rsp.DataOffset); data_area_of_src = (char *)&pSMBs->hdr.Protocol + get_unaligned_le16(&pSMBs->t2_rsp.DataOffset); data_area_of_tgt += total_in_tgt; ... memcpy(data_area_of_tgt, data_area_of_src, total_in_src); A small DataOffset can push a pointer below the actual byte area, overwriting header fields; a large one can push it past the buffer end, causing out-of-bounds heap reads (source) or writes (target). The BCC overflow guard does not prevent this: BCC reflects how much data is present, while DataOffset controls where in the buffer it starts. The "validate target area" comment present since the function was first written in 2005 was a placeholder that was never implemented. Add lower- and upper-bound checks for both data pointers before the memcpy, and before any target header fields are modified. | ||||
| CVE-2026-89632 | 1 Linux | 1 Linux Kernel | 2026-09-13 | 8.2 High |
| In the Linux kernel, the following vulnerability has been resolved: smb: client: fix use-before-check of ReparseDataLength in reparse_buf_ptr() reparse_buf_ptr() reads buf->ReparseDataLength before checking that count covers the full fixed header: buf = (struct reparse_data_buffer *)((u8 *)io + off); len = sizeof(*buf); /* 8 bytes */ rdlen = le16_to_cpu(buf->ReparseDataLength); /* offset 4, 2 bytes */ if (count < len || count < rdlen + len) /* check comes after */ struct reparse_data_buffer has ReparseDataLength at offset 4. If a server returns OutputCount < 6, the read at offset 4-5 reaches past the end of the received data. The off+count bounds against iov_len were already validated, but that does not protect against count being smaller than sizeof(*buf). Split the check: verify count >= sizeof(*buf) before reading ReparseDataLength, then verify count covers the data region. | ||||