Export limit exceeded: 28352 CVEs match your query. Please refine your search to export 10,000 CVEs or fewer.
Search
Search Results (28352 CVEs found)
| CVE | Vendors | Products | Updated | CVSS v3.1 |
|---|---|---|---|---|
| CVE-2026-113095 | 1 Google | 1 Chrome | 2026-10-22 | 8.8 High |
| Out of bounds read in Focus in Google Chrome prior to 156.0.8078.47 allowed a remote attacker to execute arbitrary code inside the sandbox via a crafted HTML page. (Chromium security severity: High) | ||||
| CVE-2026-113102 | 1 Google | 1 Chrome | 2026-10-22 | 6.5 Medium |
| Out of bounds read in FileSystem in Google Chrome prior to 156.0.8078.47 allowed a remote attacker to read memory inside the sandbox via a crafted HTML page. (Chromium security severity: Medium) | ||||
| CVE-2026-63844 | 1 Linux | 1 Linux Kernel | 2026-10-22 | 7.8 High |
| In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu/jpeg: set no_user_fence for JPEG v4.0.3 ring JPEG rings do not support 64-bit user fence writes, reject CS submissions with user fences. (cherry picked from commit 2f6afc97d259d530f4f86c7743efbc573a8da927) | ||||
| CVE-2026-63842 | 1 Linux | 1 Linux Kernel | 2026-10-22 | 7.8 High |
| In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu/jpeg: set no_user_fence for JPEG v5.0.0 ring JPEG rings do not support 64-bit user fence writes, reject CS submissions with user fences. (cherry picked from commit 0f43893d3cd478fa57836697525b338817c9c23d) | ||||
| CVE-2026-113070 | 1 Google | 1 Chrome | 2026-10-22 | 6.5 Medium |
| Out of bounds read in GetUserMedia in Google Chrome prior to 156.0.8078.47 allowed a remote attacker to read memory inside the sandbox via a crafted HTML page. (Chromium security severity: Medium) | ||||
| CVE-2026-43630 | 2 Ggml, Ggml-org | 2 Llama.cpp, Llama.cpp | 2026-10-22 | 6.5 Medium |
| llama.cpp builds b4882 before b8487 contain an out-of-bounds read vulnerability in the recurrent memory state restore path that allows attackers with write access to the slot save directory to read memory past the end of the allocated cells array. Attackers can craft a malicious slot file with an oversized seq_id value to trigger an out-of-bounds read that leaks heap data including pointer values into server logs, defeating ASLR protections and facilitating further exploitation. | ||||
| CVE-2026-95638 | 3 Adobe, Apple, Microsoft | 3 Photoshop, Macos, Windows | 2026-10-22 | 7.8 High |
| Photoshop Desktop is affected by a Heap-based Buffer Overflow vulnerability that could result in arbitrary code execution in the context of the current user. Exploitation of this issue requires user interaction in that a victim must open a malicious file. | ||||
| CVE-2026-96372 | 1 Drupal | 1 Webform | 2026-10-22 | 5.4 Medium |
| Insufficient Granularity of Access Control vulnerability in Drupal Webform allows Forceful Browsing. This issue affects Webform versions: from 0.0.0 to 6.2.12, from 6.3.0 to 6.3.1. | ||||
| CVE-2026-113329 | 2 Apple, Google | 2 Macos, Chrome | 2026-10-22 | 6.5 Medium |
| Out of bounds read in Installer in Google Chrome on on Mac prior to 156.0.8078.47 allowed a remote attacker to potentially read memory inside the sandbox via a crafted HTML page. (Chromium security severity: Medium) | ||||
| CVE-2026-113199 | 1 Google | 1 Chrome | 2026-10-22 | 6.5 Medium |
| Out of bounds read in Payments in Google Chrome prior to 156.0.8078.47 allowed a remote attacker to read memory inside the sandbox via a crafted HTML page. (Chromium security severity: Medium) | ||||
| CVE-2026-98127 | 1 Linux | 1 Linux Kernel | 2026-10-22 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: smb/client: validate new EOF for insert range smb3_insert_range() does not check if the new file size (i_size + len) is valid. This allows FALLOC_FL_INSERT_RANGE to bypass RLIMIT_FSIZE, exceed s_maxbytes, or produce a size outside the loff_t range. Use check_add_overflow() to calculate the new EOF. Validate it with inode_newsize_ok() before modifying the file. Reproducer, using a file on a CIFS mount: bash -c ' FILE=/mnt/cifs/repro trap "" SIGXFSZ ulimit -f 3072 # RLIMIT_FSIZE = 3 MiB # A regular write is stopped at 3 MiB. dd if=/dev/zero of="$FILE" bs=1M count=4 status=none stat -c "size after write: %s" "$FILE" # Insert 2 MiB into a 2 MiB file. truncate -s 2M "$FILE" fallocate -i -o 0 -l 2M "$FILE" stat -c "size after insert: %s" "$FILE" ' Before this change, the regular write stops at the 3 MiB limit, but insert range grows the file to 4 MiB: dd: error writing '/mnt/cifs/repro': File too large size after write: 3145728 size after insert: 4194304 After this change, insert range also fails at the limit and leaves the 2 MiB file unchanged: dd: error writing '/mnt/cifs/repro': File too large size after write: 3145728 fallocate: fallocate failed: File too large size after insert: 2097152 | ||||
| CVE-2026-113054 | 1 Google | 1 Chrome | 2026-10-22 | 6.5 Medium |
| Out of bounds read in SiteIsolation in Google Chrome prior to 156.0.8078.47 allowed a remote attacker to read memory inside the sandbox via a crafted HTML page. (Chromium security severity: Medium) | ||||
| CVE-2026-113050 | 1 Google | 1 Chrome | 2026-10-22 | 6.5 Medium |
| Out of bounds read in HID in Google Chrome prior to 156.0.8078.47 allowed a remote attacker to read memory inside the sandbox via a crafted HTML page. (Chromium security severity: Medium) | ||||
| CVE-2026-113151 | 1 Google | 1 Chrome | 2026-10-22 | 6.5 Medium |
| Out of bounds read in Actor in Google Chrome prior to 156.0.8078.47 allowed a remote attacker to read memory inside the sandbox via a crafted HTML page. (Chromium security severity: Medium) | ||||
| CVE-2026-91382 | 1 Oracle | 5 Graalvm, Graalvm Enterprise Edition, Graalvm For Jdk and 2 more | 2026-10-22 | 6.5 Medium |
| Vulnerability in the Oracle Java SE, Oracle GraalVM for JDK, Oracle GraalVM Enterprise Edition product of Oracle Java SE (component: 2D). Supported versions that are affected are Oracle Java SE: 8u503, 8u503-perf, 11.0.32.1, 17.0.20.1; Oracle GraalVM for JDK: 17.0.20.1 and 21.0.12.1; Oracle GraalVM Enterprise Edition: 21.3.19.1.1. Difficult to exploit vulnerability allows unauthenticated attacker with network access via multiple protocols to compromise Oracle Java SE, Oracle GraalVM for JDK, Oracle GraalVM Enterprise Edition. Successful attacks of this vulnerability can result in unauthorized creation, deletion or modification access to critical data or all Oracle Java SE, Oracle GraalVM for JDK, Oracle GraalVM Enterprise Edition accessible data and unauthorized ability to cause a partial denial of service (partial DOS) of Oracle Java SE, Oracle GraalVM for JDK, Oracle GraalVM Enterprise Edition. Note: This vulnerability can be exploited by using APIs in the specified Component, e.g., through a web service which supplies data to the APIs. This vulnerability also applies to Java deployments, typically in clients running sandboxed Java Web Start applications or sandboxed Java applets, that load and run untrusted code (e.g., code that comes from the internet) and rely on the Java sandbox for security. CVSS 3.1 Base Score 6.5 (Integrity and Availability impacts). CVSS Vector: (CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:H/A:L). | ||||
| CVE-2025-58772 | 1 Ami | 1 Aptio V | 2026-10-22 | N/A |
| AMI APTIOV contains vulnerabilities in BIOS where users may cause “Classic Buffer Overflow” by local access. Successful exploitation of this vulnerability could lead to buffer overflows, memory corruption, and arbitrary code execution, and also impact Confidentiality, Integrity, and Availability. | ||||
| CVE-2026-56386 | 1 Apache | 1 Brpc | 2026-10-22 | 7.5 High |
| Integer underflow and out-of-bounds read in the HTTP/2 server DATA frame parser in Apache bRPC allows an unauthenticated remote attacker to cause denial of service by sending a malformed DATA frame with the PADDED flag set and a zero-length payload. Root Cause: The HTTP/2 DATA frame handler computed the fragment size from the attacker-controlled payload length and, when the PADDED flag was present, decremented the fragment size before ensuring that the frame contained the mandatory pad length byte. A zero-length padded DATA frame could therefore underflow the unsigned fragment size and read the pad length byte past the end of the frame buffer. Affected Scenarios: Apache bRPC servers that accept HTTP/2 traffic are affected when a remote client can send crafted HTTP/2 frames to the server. HTTP/2 may be reached through cleartext h2c detection on an HTTP port or through TLS ALPN negotiation. How to Fix: (Choose one of the following options) 1. Upgrade Apache bRPC to version 1.18.0, which fixes this issue. 2. Apply this patch: https://github.com/apache/brpc/pull/3325 Note: The fix validates that a padded DATA frame has enough payload bytes for the pad length field before decrementing the fragment size or reading the pad length byte. Malformed zero-length padded DATA frames are rejected with HTTP/2 FRAME_SIZE_ERROR. | ||||
| CVE-2026-20179 | 1 Cisco | 4 Cisco Open Source Snort3, Cisco Secure Firewall Threat Defense (ftd) Software, Cisco Utd Snort Ips Engine Software and 1 more | 2026-10-22 | 5.8 Medium |
| Multiple Cisco products are affected by a vulnerability in the Snort 3 Generic Routing Encapsulation (GRE) Detection Engine that could allow an unauthenticated, remote attacker to cause the Snort 3 Detection Engine to restart, resulting in an interruption of packet inspection. This vulnerability is due to incomplete error checking when Snort 3 parses GRE packets. An attacker could exploit this vulnerability by sending a crafted GRE packet to a targeted device to be parsed by Snort. A successful exploit could allow the attacker to cause the Snort 3 Detection Engine to restart unexpectedly, resulting in a DoS condition. | ||||
| CVE-2026-63887 | 1 Linux | 1 Linux Kernel | 2026-10-22 | 9.8 Critical |
| In the Linux kernel, the following vulnerability has been resolved: scsi: target: iscsi: Bound iscsi_encode_text_output() appends to rsp_buf iscsi_encode_text_output() concatenates "key=value\0" records into login->rsp_buf, an 8192-byte kzalloc(MAX_KEY_VALUE_PAIRS) buffer allocated in iscsit_alloc_login_setup_buffer(). The three sprintf() call sites in this function (lines 1398, 1411, 1424 in v7.1-rc2) never check the remaining buffer capacity: *length += sprintf(output_buf, "%s=%s", er->key, er->value); *length += 1; output_buf = textbuf + *length; The 8192-byte ceiling at iscsi_target_check_login_request() bounds the *input* Login PDU payload, but a single PDU can carry up to 2048 minimal four-byte "a=b\0" pairs, each unknown key expanding to a 16-byte "a=NotUnderstood\0" output record via iscsi_add_notunderstood_response(). 2048 * 16 = 32 KiB of output into an 8 KiB buffer, producing a ~24 KiB heap overrun in the kmalloc-8k slab. The fix introduces a static iscsi_encode_text_record() helper that uses snprintf() with a per-call bounds check against the remaining buffer, and threads a u32 textbuf_size parameter through iscsi_encode_text_output(). Both call sites in iscsi_target_handle_csg_zero() (PHASE_SECURITY) and iscsi_target_handle_csg_one() (PHASE_OPERATIONAL) pass MAX_KEY_VALUE_PAIRS. On overflow the encoder logs the condition, calls iscsi_release_extra_responses() to drop queued records, and returns -1; both caller sites now emit ISCSI_STATUS_CLS_INITIATOR_ERR / ISCSI_LOGIN_STATUS_INIT_ERR via iscsit_tx_login_rsp() before returning, so the initiator sees an explicit failed-login response rather than a silent connection drop. (Prior to this patch only the PHASE_OPERATIONAL caller did that; the PHASE_SECURITY caller is converted to the same shape.) | ||||
| CVE-2026-63886 | 1 Linux | 1 Linux Kernel | 2026-10-22 | 9.8 Critical |
| In the Linux kernel, the following vulnerability has been resolved: scsi: target: iscsi: Validate CHAP_R length before base64 decode chap_server_compute_hash() allocates client_digest as kzalloc(chap->digest_size) and then, for BASE64-encoded responses, passes chap_r directly to chap_base64_decode() without checking whether the input length could produce more than digest_size bytes of output. chap_base64_decode() writes to the destination unconditionally as long as there is input to consume. With MAX_RESPONSE_LENGTH set to 128 and the "0b" prefix stripped by extract_param(), up to 127 base64 characters can reach the decoder. 127 characters decode to 95 bytes. For SHA-256 (digest_size=32) this overflows client_digest by 63 bytes; for MD5 (digest_size=16) the overflow is 79 bytes. The length check at line 344 fires after the write has already happened. The HEX branch in the same switch statement already validates the length up front. Apply the same approach to the BASE64 branch: strip trailing base64 padding characters, then reject any input whose data length exceeds DIV_ROUND_UP(digest_size * 4, 3) before calling the decoder. Stripping trailing '=' before the comparison handles both padded and unpadded encodings. chap_base64_decode() already returns early on '=', so the full original string is still passed to the decoder unchanged. The mutual CHAP path decodes CHAP_C into initiatorchg_binhex, which is kzalloc(CHAP_CHALLENGE_STR_LEN). extract_param() caps initiatorchg at CHAP_CHALLENGE_STR_LEN characters, so at most CHAP_CHALLENGE_STR_LEN-1 base64 characters reach the decoder. The maximum decoded size, DIV_ROUND_UP((CHAP_CHALLENGE_STR_LEN-1) * 3, 4), is less than CHAP_CHALLENGE_STR_LEN, so no overflow is possible there. A comment is added at the call site to document this. | ||||