Export limit exceeded: 14718 CVEs match your query. Please refine your search to export 10,000 CVEs or fewer.
Search
Search Results (24047 CVEs found)
| CVE | Vendors | Products | Updated | CVSS v3.1 |
|---|---|---|---|---|
| CVE-2026-14388 | 1 Google | 1 Chrome | 2026-08-04 | 6.5 Medium |
| Out of bounds read in ANGLE in Google Chrome prior to 150.0.7871.46 allowed a remote attacker to obtain potentially sensitive information from process memory via a crafted HTML page. (Chromium security severity: Medium) | ||||
| CVE-2026-38973 | 2026-08-04 | 4.4 Medium | ||
| mrubyc through release3.4.1 was found to contain an out-of-bounds read in builtin missing-method lookup inside mrbc_find_method(). | ||||
| CVE-2026-63943 | 1 Linux | 1 Linux Kernel | 2026-08-04 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: Input: xpad - fix out-of-bounds access for Share button xpadone_process_packet() receives len directly from urb->actual_length and uses it to index the share-button byte at data[len - 18] or data[len - 26]. Since both len and data[0] are under the device's control, a broken controller can send a GIP_CMD_INPUT packet with actual_length < 18 (e.g. 5 bytes) and reach this code path, causing accesses beyond the actual array. Fix this by calculating the offset and checking bounds against the packet length. | ||||
| CVE-2026-15903 | 1 Google | 1 Chrome | 2026-08-04 | 8.8 High |
| Out of bounds read and write in V8 in Google Chrome prior to 150.0.7871.128 allowed a remote attacker to execute arbitrary code inside a sandbox via a crafted HTML page. (Chromium security severity: High) | ||||
| CVE-2026-16418 | 1 Google | 1 Chrome | 2026-08-04 | 8.8 High |
| Stack buffer overflow in V8 in Google Chrome prior to 150.0.7871.182 allowed a remote attacker to execute arbitrary code inside a sandbox via a crafted HTML page. (Chromium security severity: High) | ||||
| CVE-2026-16419 | 1 Google | 1 Chrome | 2026-08-04 | 9.6 Critical |
| Out of bounds read and write in ANGLE in Google Chrome on Android prior to 150.0.7871.182 allowed a remote attacker to potentially perform a sandbox escape via a crafted HTML page. (Chromium security severity: High) | ||||
| CVE-2026-61390 | 1 Hikvision | 2 Ds-2cd Series, Ds-2de Series | 2026-08-04 | 7.7 High |
| There is a heap buffer overflow vulnerability in some Hikvision cameras, which may allow unauthenticated attackers to cause device malfunction by sending specially crafted packets. | ||||
| CVE-2026-61391 | 1 Hikvision | 2 Ds-2cd Series, Ds-2de Series | 2026-08-04 | 7.2 High |
| There is a stack-based buffer overflow vulnerability in some Hikvision cameras, which may allow authenticated attackers to cause device malfunction by sending specially crafted packets. | ||||
| CVE-2026-50468 | 1 Microsoft | 3 Microsoft Sql Server 2025 (cu 2), Microsoft Sql Server 2025 For X64-based Systems (gdr), Sql Server 2025 | 2026-08-03 | 6.5 Medium |
| Buffer over-read in SQL Server allows an authorized attacker to disclose information over a network. | ||||
| CVE-2026-43820 | 1 Apple | 1 Swiftnio Ssl | 2026-08-03 | 7.7 High |
| NIOSSLCertificate._subjectAlternativeNames provides access to the raw bytes for a cert's SANs. NIOSSL provides access to a buffer assumed to be backed by an ASN1_STRING, but not all SANs are backed by ASN1_STRING, so accessing the buffer for such a type can lead to out-of-bounds memory access. This vulnerability is addressed in swift-nio-ssl version 2.37.2. | ||||
| CVE-2026-18607 | 1 Wavlink | 12 Etc. Wn529, Nu516, Wn529 and 9 more | 2026-08-03 | 8.8 High |
| A security vulnerability has been detected in Wavlink WN572, WN570H, WN573, WN529, WN530, WN531, WN535, etc. WN529, WN530, WN531, WN535, WN536, WN551, WN557 and NU516 up to 20260609. Affected by this issue is the function strcpy of the file upload.cgi of the component lighttpd. The manipulation of the argument HTTP_COOKIE leads to stack-based buffer overflow. It is possible to initiate the attack remotely. The exploit has been disclosed publicly and may be used. | ||||
| CVE-2026-64223 | 1 Linux | 1 Linux Kernel | 2026-08-03 | 8.1 High |
| In the Linux kernel, the following vulnerability has been resolved: wifi: mac80211: consume only present negotiated TTLM maps ieee80211_tid_to_link_map_size_ok() validates negotiated TTLM elements against the number of link-map entries indicated by link_map_presence. ieee80211_parse_neg_ttlm() must consume the same layout. The parser advanced its cursor for every TID, including TIDs whose presence bit is clear and therefore have no map bytes in the element. A sparse map can then make a later present TID read past the validated element. The bad bytes land in neg_ttlm->{up,down}link[tid] but are gated by valid_links before being applied to driver state, so a peer cannot turn the read into a policy change. Under KUnit + KASAN with an exact-sized element allocation the OOB read is reported as a slab-out-of-bounds; whether the same trigger fires under the production RX path depends on surrounding allocator state. Advance the cursor only when the current TID has a map present. | ||||
| CVE-2026-68742 | 2 Redhat, Sssd | 4 Enterprise Linux, Openshift, Openshift Container Platform and 1 more | 2026-08-03 | 5.5 Medium |
| A flaw was found in SSSD. The sss_nss_protocol_parse_addr() function in the NSS responder does not validate the addrlen field against the remaining packet body size. A local attacker can exploit this via a crafted GETHOSTBYADDR request to the NSS responder socket, causing an out-of-bounds read and process crash, resulting in a denial of service. | ||||
| CVE-2026-18589 | 1 Wavlink | 2 Wl-nu516u1, Wl-nu516u1 Firmware | 2026-08-03 | 9.8 Critical |
| A vulnerability was found in Wavlink WL-NU516U1 708c073-mt7628. This impacts the function change_password of the file nas.cgi. The manipulation of the argument User1Passwd results in stack-based buffer overflow. The attack can be executed remotely. The exploit has been made public and could be used. The affected component should be upgraded. The vendor was contacted early, responded in a very professional manner and quickly released a fixed version of the affected product. | ||||
| CVE-2026-9390 | 1 Timlegge | 1 Xml::sig | 2026-08-03 | 9.1 Critical |
| XML::Sig versions before 0.71 for Perl allow XPath injection in ID lookup. verify() and _get_signed_xml() in lib/XML/Sig.pm build XPath expressions by concatenating the SignedInfo/Reference/@URI value read from the document being verified. The value is neither escaped nor checked against the NCName grammar that XML requires of an ID, so a URI containing a single quote closes the string literal in the generated expression and appends arbitrary XPath operators. A crafted URI can make the lookup match elements the reference does not name, or every element in the document, so which node is selected for digest verification is decided by the injected expression rather than by the reference. | ||||
| CVE-2026-18583 | 1 Mz-automation | 1 Libiec61850 | 2026-08-03 | 5.3 Medium |
| A weakness has been identified in mz-automation libiec61850 up to 1.6.1. This issue affects the function checkDataSetAccess of the file src/iec61850/server/mms_mapping/mms_mapping.c of the component MMS Request Handler. This manipulation causes out-of-bounds read. The attack can be initiated remotely. The exploit has been made available to the public and could be used for attacks. Upgrading to version 1.6.2 is capable of addressing this issue. Patch name: 062062daf4cb50c7aa76e01d6fb4d58fc9278a7d. Upgrading the affected component is recommended. The vendor was contacted early about this disclosure. | ||||
| CVE-2026-64277 | 1 Linux | 1 Linux Kernel | 2026-08-03 | 7.8 High |
| In the Linux kernel, the following vulnerability has been resolved: Input: synaptics-rmi4 - bound the F3A keymap to the GPIO count rmi_f3a_initialize() takes the GPIO count from the device query register (f3a->gpio_count = buf & RMI_F3A_GPIO_COUNT, range 0..127). rmi_f3a_map_gpios() then allocates gpio_key_map with min(gpio_count, TRACKSTICK_RANGE_END) == at most 6 entries, but rmi_f3a_attention() iterates the full gpio_count and dereferences gpio_key_map[i], and input->keycodemax is set to the full gpio_count while input->keycode points at the 6-entry allocation. A device that reports gpio_count > 6 therefore causes an out-of-bounds read of gpio_key_map[] on every attention interrupt, and out-of-bounds accesses through the input core's default keymap ioctls: EVIOCGKEYCODE reads past the buffer (leaking adjacent slab memory to user space) and EVIOCSKEYCODE writes a caller-controlled value past it, for any process able to open the evdev node, since input_default_getkeycode() and input_default_setkeycode() only bound the index against keycodemax. Size the keymap for the full gpio_count. The mapping loop is unchanged: it still assigns only the first min(gpio_count, TRACKSTICK_RANGE_END) entries; the remaining slots stay KEY_RESERVED (devm_kcalloc zero-fills) and are skipped when reporting. | ||||
| CVE-2026-64412 | 1 Linux | 1 Linux Kernel | 2026-08-03 | 7.1 High |
| In the Linux kernel, the following vulnerability has been resolved: netfilter: ebtables: module names must be null-terminated We need to explicitly check the length, else we may pass non-null terminated string to request_module(). | ||||
| CVE-2026-64445 | 1 Linux | 1 Linux Kernel | 2026-08-03 | 8.8 High |
| In the Linux kernel, the following vulnerability has been resolved: staging: rtl8723bs: fix WEP length underflow and OOB read in OnAuth() OnAuth() has two bugs in the shared-key authentication path. When the Privacy bit is set, rtw_wep_decrypt() is called without verifying that the frame is long enough to contain a valid WEP IV and ICV. Inside rtw_wep_decrypt(), length is computed as: length = len - WLAN_HDR_A3_LEN - iv_len and then passed as (length - 4) to crc32_le(). If len is less than WLAN_HDR_A3_LEN + iv_len + icv_len (32 bytes), length - 4 is negative and, after the implicit cast to size_t, causes crc32_le() to read far beyond the frame buffer. Add a minimum length check before accessing the IV field and calling the decryption path. When processing a seq=3 response, rtw_get_ie() stores the Challenge Text IE length in ie_len, but the subsequent memcmp() always reads 128 bytes regardless of ie_len. IEEE 802.11 mandates a challenge text of exactly 128 bytes; reject any IE whose length field differs, matching the check already applied to OnAuthClient(). | ||||
| CVE-2026-64450 | 1 Linux | 1 Linux Kernel | 2026-08-03 | 9.1 Critical |
| In the Linux kernel, the following vulnerability has been resolved: tipc: fix out-of-bounds read in broadcast Gap ACK blocks A broadcast PROTOCOL/STATE_MSG can carry a Gap ACK blocks record in its data area. tipc_get_gap_ack_blks() only verifies that the record's len field is self-consistent with its ugack_cnt/bgack_cnt counts (sz == struct_size(p, gacks, ugack_cnt + bgack_cnt)); it does not check that the record actually fits in the message data area, msg_data_sz(). The unicast caller tipc_link_proto_rcv() bounds it ("if (glen > dlen) break;"), but the broadcast caller tipc_bcast_sync_rcv() discards the returned size, so tipc_link_advance_transmq() copies the record off the receive skb with an attacker-controlled count: this_ga = kmemdup(ga, struct_size(ga, gacks, ga->bgack_cnt), GFP_ATOMIC); A TIPC neighbour that negotiated TIPC_GAP_ACK_BLOCK triggers it with one ordinary broadcast STATE_MSG (msg_bc_ack_invalid() clear), sized so its data area is short, carrying a Gap ACK record with len = 0x400, bgack_cnt = 0xff and ugack_cnt = 0. len then equals struct_size(p, gacks, 255), so the consistency check passes and ga is non-NULL; kmemdup() reads struct_size(ga, gacks, 255) = 1024 bytes out of the much smaller skb: BUG: KASAN: slab-out-of-bounds in kmemdup_noprof+0x48/0x60 Read of size 1024 at addr ffff0000c7030d38 by task poc864/69 Call trace: kmemdup_noprof+0x48/0x60 tipc_link_advance_transmq+0x86c/0xb80 tipc_link_bc_ack_rcv+0x19c/0x1e0 tipc_bcast_sync_rcv+0x1c4/0x2c4 tipc_rcv+0x85c/0x1340 tipc_l2_rcv_msg+0xac/0x104 The buggy address belongs to the object at ffff0000c7030d00 which belongs to the cache skbuff_small_head of size 704 The buggy address is located 56 bytes inside of allocated 704-byte region [ffff0000c7030d00, ffff0000c7030fc0) The copied-out bytes are subsequently consumed as gap/ack values, but the read is already out of bounds at the kmemdup() regardless of how they are used. The unicast STATE path drops such a message: "if (glen > dlen) break;" skips the rest of STATE_MSG handling and the skb is freed. Make the broadcast path drop it too. tipc_bcast_sync_rcv() now bounds the record against msg_data_sz() and, when it does not fit, reports it back through tipc_node_bc_sync_rcv() to tipc_rcv() so the skb is discarded rather than processed. ga is not cleared on this path: ga == NULL already means "legacy peer without Selective ACK", a distinct legitimate state. | ||||