Export limit exceeded: 25197 CVEs match your query. Please refine your search to export 10,000 CVEs or fewer.
Search
Search Results (25197 CVEs found)
| CVE | Vendors | Products | Updated | CVSS v3.1 |
|---|---|---|---|---|
| CVE-2026-18238 | 2026-09-05 | 5 Medium | ||
| The rpcap client code that processes a RPCAP_MSG_PACKET message received from the server incorrectly validates its headers. A malicious server can send a crafted message and cause the client to treat up to 20 bytes of the client process memory beyond the end of the buffer as if it was a part of the captured packet. | ||||
| CVE-2026-31912 | 2026-09-05 | 5.5 Medium | ||
| libpcap BPF interpreter detects neither reaching the end of the filter program buffer due to lack of a return instruction nor executing a jump instruction with an offset that translates to a pointer outside of the buffer. In particular uncommon use cases a crafted filter program can cause the interpreter to try reading the OS process memory in the 32GiB around the buffer on 64-bit architectures and in the entire address space on 32-bit architectures. | ||||
| CVE-2026-0799 | 2026-09-05 | 8.7 High | ||
| In BPF instructions that load/store a value from/to a scratch memory register the register index is an unsigned 32-bit integer and must not exceed 15, but libpcap BPF interpreter does not validate the value. In particular uncommon use cases a crafted filter program can cause the interpreter to try reading and writing the OS process memory in the 16GiB starting at the current stack frame on 64-bit architectures and in the entire address space on 32-bit architectures. | ||||
| CVE-2026-82752 | 1 Ash-project | 1 Ash | 2026-09-05 | N/A |
| Improper Validation of Specified Quantity in Input vulnerability in ash-project ash allows an attacker to store a value of arbitrary size in an attribute whose length constraint should bound it. Ash measures string length with Elixir's String.length/1, which counts Unicode graphemes, in the max_length and min_length constraints of Ash.Type.String (apply_constraints/2 in lib/ash/type/string.ex), in Ash.Resource.Validation.StringLength, and in the string_length expression function. A grapheme carries an unbounded number of combining marks, so a base character followed by a million combining acute accents is one grapheme and megabytes of data, and satisfies max_length: 2. Where the data layer imposes no independent limit (ETS, Mnesia, or a Postgres text column) the whole value is persisted, so an attacker can write an entire request body into an attribute declared with a small maximum and grow storage without bound. The counting unit also disagrees with the storage layer, which counts codepoints rather than graphemes, so a value accepted by the constraint can still be rejected or truncated by the column. A Postgres varchar(n) column bounds the value itself and is not exposed. This issue affects ash: from 0.10.0 before 3.33.0. | ||||
| CVE-2025-15647 | 2026-09-05 | 5.5 Medium | ||
| CDT before 1.4.5 contains an out-of-bounds read vulnerability in the opposedVertexInd() function when constraint edge intersections are computed in floating point and round outside adjacent triangles. Attackers can supply nearly-degenerate constraint edges through geometry data to trigger an out-of-bounds array access that crashes the calling process. | ||||
| CVE-2025-15614 | 2026-09-05 | 3.3 Low | ||
| ugrep before 7.6.0 contains a heap buffer over-read vulnerability in the LZW decompressor when processing crafted .Z archive files. Attackers can supply malformed .Z files that cause the decompressor to read one byte past the allocated heap buffer, potentially crashing the process. | ||||
| CVE-2026-86142 | 1 Xmlsoft | 1 Libxml2 | 2026-09-05 | 6.9 Medium |
| In libxml2 before 2.15.4, there is a heap-based buffer overflow in xmlXPtrEvalXPtrPart because of xmlXPtrEval xpointer length saturation. | ||||
| CVE-2026-86137 | 1 Xmlsoft | 1 Libxml2 | 2026-09-05 | 2.9 Low |
| In libxml2 before 2.15.4, xmlFAParsePosCharGroup has an out-of-bounds read, aka an out-of-bounds read in the NXT macro in xmlregexp. | ||||
| CVE-2026-86140 | 1 Xmlsoft | 1 Libxml2 | 2026-09-05 | 8 High |
| In libxml2 before 2.15.4, xmlSnprintfElements in valid.c has a strcat stack-based buffer overflow. | ||||
| CVE-2026-85444 | 1 Moos-ivp | 1 Moos-ivp | 2026-09-05 | 7.5 High |
| MOOS-IvP through 24.8.1 contains a buffer over-read vulnerability in isQuoted(), isBraced(), and isChevroned() functions that strip whitespace but index using the original string length. Attackers can send NODE_REPORT messages with leading or trailing whitespace to read past buffer bounds and access adjacent memory. | ||||
| CVE-2026-71222 | 1 Redhat | 2 Enterprise Linux, Gfs2-utils | 2026-09-05 | 5.3 Medium |
| A heap out-of-bounds read vulnerability was found in gfs2-utils. The ea_num_ptrs field from on-disk extended attribute metadata is consumed without bounds validation, causing a heap buffer over-read that may disclose sensitive memory contents or cause a crash when processing crafted GFS2 filesystem images. | ||||
| CVE-2026-52763 | 1 Yeswiki | 1 Yeswiki | 2026-09-05 | 6.5 Medium |
| YesWiki is a wiki system written in PHP. Prior to version 4.6.6, the recentchanges action (actions/recentchanges.php) accepts a period argument from two disjoint parameter spaces. A whitelist validates only the URL form against ['day','week','month']. The action-argument form takes the else branch with no validation, and the value flows into PageManager::getRecentlyChanged(), where it is interpolated into a WHERE time >= '...' ORDER BY time DESC clause without escaping or parameterization. UNION-based injection succeeds, the leaked rows render into the response page, so any visitor of the trigger page sees the exfiltrated data. The vulnerability provides arbitrary read of the YesWiki database to anyone who can save the trigger page. On a default install (default_write_acl='*'), this includes anonymous users, subject to the hashcash JS check on the page-edit form. Once the trigger page is saved, every subsequent view fires the injection as the SQLi is stored. Stored SQL injection is reachable through the page-edit flow, with arbitrary database read. This issue has been patched in version 4.6.6. | ||||
| CVE-2026-85090 | 1 Freerdp | 1 Freerdp | 2026-09-05 | 5.4 Medium |
| FreeRDP before 3.31.0 contains a heap out-of-bounds read vulnerability in the general_ChromaV1ToYUV444 function during AVC444 chroma plane reconstruction. A malicious RDP server can craft a RFX_AVC444_BITMAP_STREAM with specific frame geometry to trigger an out-of-bounds memory read past the allocated luma plane. | ||||
| CVE-2026-57165 | 1 Pjsip | 1 Pjproject | 2026-09-04 | N/A |
| PJSIP is a free and open source multimedia communication library written in C. Prior to commit 628b716, a stack buffer overflow exists in the PJLIB-UTIL telnet CLI front-end when redrawing the command line during history recall (handle_up_down() in cli_telnet.c). This affects only applications that enable the telnet CLI front-end (same gating as the related CLI issue). The line-redraw sequence for a recalled history entry can accumulate more data than a fixed-size stack buffer holds, which may lead to application termination. Exploitation requires access to the unauthenticated telnet CLI, which already permits arbitrary CLI commands, so the additional impact is limited. Applications that do not enable the telnet CLI front-end are not affected. This issue has been patched via commit 628b716. | ||||
| CVE-2026-57161 | 1 Pjsip | 1 Pjproject | 2026-09-04 | N/A |
| PJSIP is a free and open source multimedia communication library written in C. Prior to commit acc03b5, a stack buffer overflow exists in PJSUA when processing Service-Route headers in a registration response (update_service_route() in pjsua_acc.c). This affects applications that register using the PJSUA/PJSUA2 account API (the default registration path). The Service-Route URIs from a 2xx response to REGISTER are stored into a fixed-size array without bounding the number of headers; a registrar that returns an excessive number of Service-Route headers can write past the end of the array on the stack. The values written are internal pointers rather than arbitrary data, so the most likely impact is unexpected application termination (denial of service), though memory corruption cannot be excluded. The malicious response may come from a compromised or malicious registrar, or — over unprotected transports — a spoofed response. This issue has been patched via commit acc03b5. | ||||
| CVE-2026-57162 | 1 Pjsip | 1 Pjproject | 2026-09-04 | N/A |
| PJSIP is a free and open source multimedia communication library written in C. Prior to commit a1b707c, a stack buffer overflow exists in the SRTP/SDES media transport when processing a=crypto attributes during SDP offer/answer (sdes_encode_sdp() in transport_srtp_sdes.c). This affects applications with SRTP enabled (use_srtp optional or mandatory, using SDES keying). During media negotiation, the crypto attributes from the remote SDP are collected into a fixed-size array without bounding their number; a remote peer that includes an excessive number of a=crypto attributes in a single media description can write past the end of that array on the stack. This is reachable from an incoming SIP INVITE during offer/answer, before application-level authentication. Impact may range from unexpected application termination to control flow hijack/memory corruption. Applications that do not enable SRTP are not affected. This issue has been patched via commit a1b707c. | ||||
| CVE-2026-57163 | 1 Pjsip | 1 Pjproject | 2026-09-04 | N/A |
| PJSIP is a free and open source multimedia communication library written in C. Prior to commit c4a151a, a stack buffer overflow exists in the GnuTLS TLS backend when parsing the Subject Alternative Name extension of a peer certificate (tls_cert_get_info() in ssl_sock_gtls.c). Only GnuTLS builds are affected (--with-gnutls); OpenSSL and Apple SecureTransport/Network.framework builds are not affected. While extracting certificate information after a TLS handshake, an incorrect buffer-size value can cause an oversized SubjectAltName entry to be written past the end of a fixed-size stack buffer. A network-positioned attacker presenting a crafted certificate — a malicious server to a connecting client, or a malicious client to a server that requests certificates — can trigger this during the TLS handshake, before any SIP-level authentication. Impact may range from unexpected application termination to control flow hijack/memory corruption. This issue has been patched via commit c4a151a. | ||||
| CVE-2026-80800 | 1 Linux | 1 Linux Kernel | 2026-09-04 | N/A |
| In the Linux kernel, the following vulnerability has been resolved: nfc: llcp: bound the connect_sn TLV walk to the skb Commit 27256cdb290e ("nfc: llcp: bound SNL TLV parsing to the skb and add length checks") fixed the unbounded TLV walk in nfc_llcp_recv_snl(), and commit d8bd2dedbde5 ("nfc: llcp: fix OOB read and u8 offset wrap in TLV parsers") subsequently bounded nfc_llcp_parse_gb_tlv() and nfc_llcp_parse_connection_tlv(). One sibling parser sharing the same pattern remains unbounded: nfc_llcp_connect_sn(). nfc_llcp_connect_sn() walks a TLV list, reading a two-byte header (type, length) followed by length bytes of value, without checking that the two header bytes or the declared length stay within the buffer. It returns a pointer to a service name of up to 255 bytes that may point past the end of the skb; it is subsequently consumed by memcmp() in nfc_llcp_sock_from_sn(). In addition tlv_array_len was computed as "skb->len - LLCP_HEADER_SIZE" in size_t, so a CONNECT/CC frame shorter than the LLCP header underflows to a huge length and the walk runs far past the buffer. nfc_llcp_connect_sn() is reachable from nfc_llcp_recv_connect() and nfc_llcp_recv_cc(), i.e. from received CONNECT and CC PDUs. A nearby NFC device can reach this without authentication; LLCP link activation happens automatically after NFC-DEP, and the nfc_llcp_rx_skb() dispatcher applies no minimum-length guard. Walk the TLV list by pointer, bounded by skb_tail_pointer(skb), and validate each declared length before use, matching the approach already used for nfc_llcp_recv_snl(). Starting the walk at &skb->data[LLCP_HEADER_SIZE] against the tail pointer also removes the size_t underflow for short frames. Found by 0sec automated security-research tooling (https://0sec.ai). | ||||
| CVE-2026-80765 | 1 Linux | 1 Linux Kernel | 2026-09-04 | N/A |
| In the Linux kernel, the following vulnerability has been resolved: HID: hyperv: validate initial device info bounds The Hyper-V synthetic HID host supplies SYNTH_HID_INITIAL_DEVICE_INFO messages that contain a HID descriptor followed by the report descriptor bytes. mousevsc_on_receive_device_info() trusts bLength and wDescriptorLength without checking that the received packet contains both byte ranges. A malformed host or backend message can therefore make the guest read past the received VMBus packet while copying the report descriptor. Pass the received initial-device-info size into the parser and reject descriptor lengths that exceed the packet. Impact: A malicious Hyper-V host or backend can crash a guest by sending a short initial device-info message with an oversized HID report descriptor length. | ||||
| CVE-2026-80772 | 1 Linux | 1 Linux Kernel | 2026-09-04 | N/A |
| In the Linux kernel, the following vulnerability has been resolved: HID: nintendo: fix out-of-bounds read in joycon_ctlr_read_handler() joycon_ctlr_read_handler() casts an incoming HID input report to struct joycon_input_report and parses it, guarding the cast only with a 12-byte length check: if (size >= 12) /* make sure it contains the input report */ joycon_parse_report(ctlr, (struct joycon_input_report *)data); struct joycon_input_report is 49 bytes: a 13-byte header followed by a union whose IMU arm is 36 bytes. For an IMU report joycon_parse_report() -> joycon_parse_imu_report() walks that union (struct offsets 13..48), so a report of exactly 12 bytes with data[0] == JC_INPUT_IMU_DATA passes the guard yet is read up to 37 bytes past its declared length. The over-read bytes are decoded into accelerometer/gyroscope values and forwarded to userspace through the "(IMU)" input device, leaking driver-internal memory. data[0] and size are fully controlled by a malicious or spoofed Joy-Con/Pro Controller. Receive buffers are sized to the maximum report length, so this is an over-read within the allocation rather than a slab OOB, but the decoded bytes still reach userspace. The sibling subcmd path in joycon_ctlr_handle_event() already bounds the same cast correctly: if (size < sizeof(struct joycon_input_report) || data[0] != JC_INPUT_SUBCMD_REPLY) break; Use the same sizeof(struct joycon_input_report) bound here. | ||||