Export limit exceeded: 404235 CVEs match your query. Please refine your search to export 10,000 CVEs or fewer.
Export limit exceeded: 10780 CVEs match your query. Please refine your search to export 10,000 CVEs or fewer.
Export limit exceeded: 51798 CVEs match your query. Please refine your search to export 10,000 CVEs or fewer.
Search
Search Results (51798 CVEs found)
| CVE | Vendors | Products | Updated | CVSS v3.1 |
|---|---|---|---|---|
| CVE-2026-106332 | 1 Google | 1 Chrome | 2026-10-07 | 4.3 Medium |
| Integer overflow in Compositing in Google Chrome prior to 155.0.8059.39 allowed a remote attacker to obtain cross-origin data via a crafted HTML page. (Chromium security severity: High) | ||||
| CVE-2026-106292 | 1 Google | 1 Chrome | 2026-10-07 | 8.3 High |
| Buffer overflow in Fonts in Google Chrome prior to 155.0.8059.39 allowed a remote attacker who had compromised the renderer process to potentially execute arbitrary code outside the sandbox via a crafted HTML page. (Chromium security severity: Medium) | ||||
| CVE-2026-102408 | 1 Elastic | 1 Elasticsearch | 2026-10-07 | 4.3 Medium |
| Inefficient Regular Expression Complexity (CWE-1333) in Elasticsearch can lead to denial of service via Regular Expression Exponential Blowup (CAPEC-492). The ES|QL CHUNK function's recursive chunking strategy accepts a list of user-supplied regular expressions used as text-splitting separators, without validating their computational complexity or bounding their execution time. An authenticated user with read access to any text-based index can submit a specially crafted regular expression that triggers catastrophic backtracking, consuming excessive CPU on Elasticsearch worker threads and degrading query throughput for other tenants on the affected node. The cluster does not crash as a result of this issue. | ||||
| CVE-2026-106311 | 1 Google | 1 Chrome | 2026-10-07 | 5.4 Medium |
| Clickjacking in PermissionElement in Google Chrome prior to 155.0.8059.39 allowed a remote attacker leveraging social engineering to spoof UI elements via a crafted HTML page. (Chromium security severity: Medium) | ||||
| CVE-2026-106400 | 1 Google | 2 Android, Chrome | 2026-10-07 | 5.4 Medium |
| Clickjacking in Messages in Google Chrome on on Android prior to 155.0.8059.39 allowed a remote attacker leveraging social engineering to spoof UI elements via a crafted HTML page. (Chromium security severity: Medium) | ||||
| CVE-2026-106247 | 1 Google | 1 Chrome | 2026-10-07 | 8.3 High |
| Buffer overflow in ANGLE in Google Chrome prior to 155.0.8059.39 allowed a remote attacker who had compromised the renderer process to potentially execute arbitrary code outside the sandbox via a crafted HTML page. (Chromium security severity: Low) | ||||
| CVE-2026-106417 | 1 Google | 1 Chrome | 2026-10-07 | 9.6 Critical |
| Integer overflow in Media in Google Chrome prior to 155.0.8059.39 allowed a remote attacker to potentially execute arbitrary code outside the sandbox via a crafted HTML page. (Chromium security severity: Low) | ||||
| CVE-2026-28667 | 1 Google | 1 Android | 2026-10-07 | 5.5 Medium |
| In multiple functions of rw_t5t.cc, there is a possible out-of-bounds read due to a missing bounds check. This could lead to local information disclosure with no additional execution privileges needed. User interaction is not needed for exploitation. | ||||
| CVE-2026-49880 | 1 Google | 1 Android | 2026-10-07 | 7.8 High |
| In multiple functions of nfa_nfcee_act.cc, there is a possible out-of-bounds write due to a missing bounds check. This could lead to local escalation of privilege with no additional execution privileges needed. User interaction is not needed for exploitation. | ||||
| CVE-2026-49885 | 1 Google | 1 Android | 2026-10-07 | 7.8 High |
| In rw_t4t_update_file of rw_t4t.cc, there is a possible out-of-bounds write due to an integer overflow. This could lead to local escalation of privilege with no additional execution privileges needed. User interaction is not needed for exploitation. | ||||
| CVE-2026-98254 | 1 Linux | 1 Linux Kernel | 2026-10-07 | 7.8 High |
| In the Linux kernel, the following vulnerability has been resolved: swiotlb: use the adjusted address for the highmem page lookup swiotlb_bounce() reads the page frame number from the slot's recorded orig_addr, then advances orig_addr by tlb_offset to reach the address the caller asked about. The highmem branch mixes the two: the offset within the page comes from the adjusted address, the page from the value before it. Once the adjustment crosses a page boundary the pair no longer describes one location, and the whole copy lands one page below the intended one for a positive tlb_offset, one above for a negative one. DMA_FROM_DEVICE writes the device data over the wrong page and leaves the intended one stale, DMA_TO_DEVICE feeds the device from a page the mapping may not cover. Partial syncs through dma_sync_single_range_for_*() are what make tlb_offset non-zero. The branch test is picked the same way, so a slot recorded in lowmem can be adjusted into highmem and the lowmem path then hands a highmem address to phys_to_virt(). Take both from orig_addr once it is final and keep pfn in the branch that uses it. PhysHighMem() asks the question straight from the address, as dma-debug already does. | ||||
| CVE-2026-83742 | 1 Wolfssl | 1 Wolfssh | 2026-10-07 | N/A |
| Unsigned integer underflow in wstrncat() in src/port.c in wolfSSL wolfSSH from v1.4.11 through v1.5.0 on non-Windows platforms allows an authenticated remote attacker to write one out-of-bounds null byte past the end of a stack buffer by sending a crafted SFTP path. wolfSSH_RealPath() in src/ssh.c appends each path component with a remaining-size bound (outSz - curSz) rather than the full destination size, so once the accumulated path reaches half the output buffer the size_t computation n - strlen(s1) - 1 wraps to near SIZE_MAX. The strncat() call is then effectively unbounded and copies the whole component; when that component exactly fills the remainder of the buffer, its terminating null is written one byte past the end. The caller's own length check keeps the copied data inside the buffer, so the overflow is limited to that single null byte, which may corrupt an adjacent stack value and crash the process. Applications that call the public wolfSSH_RealPath() with an output buffer smaller than the input path are additionally exposed to an unbounded copy, because the word32 expression outSz - segSz in that length check also wraps. | ||||
| CVE-2026-93517 | 2026-10-07 | 7.8 High | ||
| A flaw was found in xorg-x11-server. The GLX (OpenGL Extension to the X Window System) interface fails to verify that incoming data sizes do not exceed allocated buffer limits when handling large rendering requests. An authenticated local client can exploit this vulnerability by sending a specially crafted request, triggering a heap-based buffer overflow. Successful exploitation can result in arbitrary code execution with the privileges of the X server or cause a Denial of Service (DoS) by crashing the application. | ||||
| CVE-2026-93524 | 2026-10-07 | 3.3 Low | ||
| A flaw was found in xorg-x11-server. An authenticated local user can trigger an out-of-bounds heap memory read by sending specially crafted X Keyboard Extension (XKB) requests with inconsistent key range parameters. This flaw leads to information disclosure, allowing the user to read sensitive data from the server's heap memory. | ||||
| CVE-2026-88812 | 2026-10-07 | 7.8 High | ||
| A flaw was found in the X.Org X Server and XWayland. An error handling issue in the X Keyboard Extension (XKB) geometry processing fails to clear a memory pointer after an allocation failure, leading to a double-free condition during cleanup. A local user can exploit this vulnerability by sending a specially crafted request to the display server. This can cause memory corruption, potentially resulting in a Denial of Service (DoS) or arbitrary code execution with elevated privileges. | ||||
| CVE-2026-98241 | 1 Linux | 1 Linux Kernel | 2026-10-07 | 7.8 High |
| In the Linux kernel, the following vulnerability has been resolved: ipv6: xfrm: use full sockets in local error paths xfrm6_local_rxpmtu() and xfrm6_local_error() dereference skb->sk as if it always pointed at a full IPv6 socket. That is not guaranteed. TCP SYN-ACK skbs can be owned by a TCP_NEW_SYN_RECV request_sock while the output path itself is driven by the full listener. If rerouting selects an IPv6 XFRM tunnel route with a lower MTU, the local PMTU/error handling path can reach these callbacks with that mini-socket still attached to the skb. The callbacks then miscast the request socket as a full inet/IPv6 socket and can read beyond the request_sock allocation when they access inet_sock or ipv6_pinfo state. Resolve the owner with skb_to_full_sk() in both callbacks and bail out when no full socket is attached. This matches the surrounding XFRM IPv6 PMTU/error logic, which already reasons about full sockets with skb_to_full_sk(). | ||||
| CVE-2026-98282 | 1 Linux | 1 Linux Kernel | 2026-10-07 | 8.8 High |
| In the Linux kernel, the following vulnerability has been resolved: powerpc/iommu: Fix the overflow validation in iommu_tce_check_ioba The commit b1af23d836f8 ("KVM: PPC: iommu: Unify TCE checking") unified IOBA parameter checking across KVM and VFIO into iommu_tce_check_ioba(). While doing so, the passed in argument npages is ignored and constant value '1' is used leaving out a possible overflow as the callers can legitimately be using npages > 1 for H_STUFF_TCE or H_PUT_TCE_INDIRECT cases. Fix this by accounting for 'npages', checking for arithmetic overflow, and verifying that the entire requested range (ioba - offset + npages) does not exceed the table capacity 'size'. | ||||
| CVE-2026-106356 | 1 Google | 1 Chrome | 2026-10-07 | 5.4 Medium |
| Clickjacking in EVP in Google Chrome prior to 155.0.8059.39 allowed a remote attacker leveraging social engineering to spoof UI elements via a crafted HTML page. (Chromium security severity: Medium) | ||||
| CVE-2026-98348 | 1 Linux | 1 Linux Kernel | 2026-10-07 | 7.1 High |
| In the Linux kernel, the following vulnerability has been resolved: wifi: libipw: reject too-short association responses libipw_handle_assoc_resp() reads the capability, status and aid fields of the 30-byte association response prefix and then computes the information element length as stats->len - sizeof(*frame) stats->len is a u16 and sizeof() has type size_t, so the subtraction is evaluated as size_t and wraps instead of going negative. Truncating that to the u16 length parameter of libipw_parse_info_param() turns a frame shorter than the fixed fields into a length near 64 KiB, and the parser then reads past the receive buffer. Both the ipw2100 and ipw2200 management receive paths reach this function having established only that the frame carries the generic 24-byte three-address header. Reject the frame before any fixed field is touched. Found by an AI-assisted review of length arithmetic in management frame parsers. Verified with a KUnit case under Generic KASAN on arm64 under QEMU; I do not have the hardware, so it is not tested on a real device. | ||||
| CVE-2026-98323 | 1 Linux | 1 Linux Kernel | 2026-10-07 | 9.8 Critical |
| In the Linux kernel, the following vulnerability has been resolved: RDMA/siw: Bound fragmented header copies by the remaining length siw_get_hdr() can receive an extended DDP/RDMAP header across more than one TCP callback. The first callback may receive most of the header, while the next one still limits the copy to hdrlen - MIN_DDP_HDR instead of the number of missing bytes. This makes the destination move past the end of the header and overwrite the receive state, including fpdu_part_rcvd. A later callback can then use a negative fpdu_part_rcvd value as a copy offset, which creates an OOB write. Use the number of header bytes already received when calculating the next copy length. | ||||