Total
17258 CVE
| CVE | Vendors | Products | Updated | CVSS v2 | CVSS v3 |
|---|---|---|---|---|---|
| CVE-2026-8010 | 4 Apple, Google, Linux and 1 more | 4 Macos, Chrome, Linux Kernel and 1 more | 2026-05-07 | N/A | 6.3 MEDIUM |
| Insufficient validation of untrusted input in SiteIsolation in Google Chrome prior to 148.0.7778.96 allowed a remote attacker who had compromised the renderer process to bypass site isolation via a crafted HTML page. (Chromium security severity: Low) | |||||
| CVE-2026-8011 | 4 Apple, Google, Linux and 1 more | 4 Macos, Chrome, Linux Kernel and 1 more | 2026-05-07 | N/A | 4.3 MEDIUM |
| Insufficient policy enforcement in Search in Google Chrome prior to 148.0.7778.96 allowed a remote attacker to leak cross-origin data via a crafted HTML page. (Chromium security severity: Low) | |||||
| CVE-2026-8014 | 4 Apple, Google, Linux and 1 more | 4 Macos, Chrome, Linux Kernel and 1 more | 2026-05-07 | N/A | 4.3 MEDIUM |
| Inappropriate implementation in Preload in Google Chrome prior to 148.0.7778.96 allowed a remote attacker to leak cross-origin data via a crafted HTML page. (Chromium security severity: Low) | |||||
| CVE-2026-8022 | 4 Apple, Google, Linux and 1 more | 4 Macos, Chrome, Linux Kernel and 1 more | 2026-05-07 | N/A | 3.1 LOW |
| Inappropriate implementation in MHTML in Google Chrome prior to 148.0.7778.96 allowed a remote attacker who convinced a user to engage in specific UI gestures to leak cross-origin data via a crafted MHTML page. (Chromium security severity: Low) | |||||
| CVE-2026-7981 | 4 Apple, Google, Linux and 1 more | 4 Macos, Chrome, Linux Kernel and 1 more | 2026-05-07 | N/A | 8.1 HIGH |
| Out of bounds read in Codecs in Google Chrome prior to 148.0.7778.96 allowed a remote attacker to obtain potentially sensitive information from process memory via a malicious file. (Chromium security severity: Medium) | |||||
| CVE-2026-8001 | 3 Apple, Google, Linux | 4 Macos, Chrome, Chrome Os and 1 more | 2026-05-07 | N/A | 8.3 HIGH |
| Use After Free in Printing in Google Chrome on Linux, Mac, ChromeOS prior to 148.0.7778.96 allowed a remote attacker who had compromised the renderer process to potentially perform a sandbox escape via a crafted HTML page. (Chromium security severity: Low) | |||||
| CVE-2026-8002 | 4 Apple, Google, Linux and 1 more | 4 Macos, Chrome, Linux Kernel and 1 more | 2026-05-07 | N/A | 8.8 HIGH |
| Use after free in Audio in Google Chrome on Mac prior to 148.0.7778.96 allowed a remote attacker to execute arbitrary code inside a sandbox via a crafted HTML page. (Chromium security severity: Low) | |||||
| CVE-2026-8003 | 4 Apple, Google, Linux and 1 more | 4 Macos, Chrome, Linux Kernel and 1 more | 2026-05-07 | N/A | 5.4 MEDIUM |
| Insufficient validation of untrusted input in TabGroups in Google Chrome prior to 148.0.7778.96 allowed a remote attacker to perform UI spoofing via malicious network traffic. (Chromium security severity: Low) | |||||
| CVE-2026-8004 | 4 Apple, Google, Linux and 1 more | 4 Macos, Chrome, Linux Kernel and 1 more | 2026-05-07 | N/A | 4.3 MEDIUM |
| Insufficient policy enforcement in DevTools in Google Chrome prior to 148.0.7778.96 allowed an attacker who convinced a user to install a malicious extension to leak cross-origin data via a crafted Chrome Extension. (Chromium security severity: Low) | |||||
| CVE-2026-8005 | 4 Apple, Google, Linux and 1 more | 4 Macos, Chrome, Linux Kernel and 1 more | 2026-05-07 | N/A | 4.3 MEDIUM |
| Insufficient validation of untrusted input in Cast in Google Chrome prior to 148.0.7778.96 allowed an attacker on the local network segment to bypass same origin policy via malicious network traffic. (Chromium security severity: Low) | |||||
| CVE-2026-7998 | 4 Apple, Google, Linux and 1 more | 4 Macos, Chrome, Linux Kernel and 1 more | 2026-05-07 | N/A | 5.4 MEDIUM |
| Insufficient validation of untrusted input in Dialog in Google Chrome prior to 148.0.7778.96 allowed a remote attacker who had compromised the renderer process to perform UI spoofing via a crafted HTML page. (Chromium security severity: Low) | |||||
| CVE-2026-7999 | 4 Apple, Google, Linux and 1 more | 4 Macos, Chrome, Linux Kernel and 1 more | 2026-05-07 | N/A | 4.3 MEDIUM |
| Inappropriate implementation in V8 in Google Chrome prior to 148.0.7778.96 allowed a remote attacker to obtain potentially sensitive information from process memory via a crafted HTML page. (Chromium security severity: Low) | |||||
| CVE-2026-8000 | 4 Apple, Google, Linux and 1 more | 4 Macos, Chrome, Linux Kernel and 1 more | 2026-05-07 | N/A | 8.8 HIGH |
| Insufficient validation of untrusted input in ChromeDriver in Google Chrome on Windows prior to 148.0.7778.96 allowed a remote attacker to execute arbitrary code via a crafted HTML page. (Chromium security severity: Low) | |||||
| CVE-2026-31693 | 1 Linux | 1 Linux Kernel | 2026-05-07 | N/A | 7.8 HIGH |
| In the Linux kernel, the following vulnerability has been resolved: cifs: some missing initializations on replay In several places in the code, we have a label to signify the start of the code where a request can be replayed if necessary. However, some of these places were missing the necessary reinitializations of certain local variables before replay. This change makes sure that these variables get initialized after the label. | |||||
| CVE-2025-37756 | 2 Debian, Linux | 2 Debian Linux, Linux Kernel | 2026-05-07 | N/A | 5.5 MEDIUM |
| In the Linux kernel, the following vulnerability has been resolved: net: tls: explicitly disallow disconnect syzbot discovered that it can disconnect a TLS socket and then run into all sort of unexpected corner cases. I have a vague recollection of Eric pointing this out to us a long time ago. Supporting disconnect is really hard, for one thing if offload is enabled we'd need to wait for all packets to be _acked_. Disconnect is not commonly used, disallow it. The immediate problem syzbot run into is the warning in the strp, but that's just the easiest bug to trigger: WARNING: CPU: 0 PID: 5834 at net/tls/tls_strp.c:486 tls_strp_msg_load+0x72e/0xa80 net/tls/tls_strp.c:486 RIP: 0010:tls_strp_msg_load+0x72e/0xa80 net/tls/tls_strp.c:486 Call Trace: <TASK> tls_rx_rec_wait+0x280/0xa60 net/tls/tls_sw.c:1363 tls_sw_recvmsg+0x85c/0x1c30 net/tls/tls_sw.c:2043 inet6_recvmsg+0x2c9/0x730 net/ipv6/af_inet6.c:678 sock_recvmsg_nosec net/socket.c:1023 [inline] sock_recvmsg+0x109/0x280 net/socket.c:1045 __sys_recvfrom+0x202/0x380 net/socket.c:2237 | |||||
| CVE-2026-31589 | 1 Linux | 1 Linux Kernel | 2026-05-07 | N/A | 9.8 CRITICAL |
| In the Linux kernel, the following vulnerability has been resolved: mm: call ->free_folio() directly in folio_unmap_invalidate() We can only call filemap_free_folio() if we have a reference to (or hold a lock on) the mapping. Otherwise, we've already removed the folio from the mapping so it no longer pins the mapping and the mapping can be removed, causing a use-after-free when accessing mapping->a_ops. Follow the same pattern as __remove_mapping() and load the free_folio function pointer before dropping the lock on the mapping. That lets us make filemap_free_folio() static as this was the only caller outside filemap.c. | |||||
| CVE-2026-31774 | 1 Linux | 1 Linux Kernel | 2026-05-07 | N/A | 7.1 HIGH |
| In the Linux kernel, the following vulnerability has been resolved: io_uring/net: fix slab-out-of-bounds read in io_bundle_nbufs() sqe->len is __u32 but gets stored into sr->len which is int. When userspace passes sqe->len values exceeding INT_MAX (e.g. 0xFFFFFFFF), sr->len overflows to a negative value. This negative value propagates through the bundle recv/send path: 1. io_recv(): sel.val = sr->len (ssize_t gets -1) 2. io_recv_buf_select(): arg.max_len = sel->val (size_t gets 0xFFFFFFFFFFFFFFFF) 3. io_ring_buffers_peek(): buf->len is not clamped because max_len is astronomically large 4. iov[].iov_len = 0xFFFFFFFF flows into io_bundle_nbufs() 5. io_bundle_nbufs(): min_t(int, 0xFFFFFFFF, ret) yields -1, causing ret to increase instead of decrease, creating an infinite loop that reads past the allocated iov[] array This results in a slab-out-of-bounds read in io_bundle_nbufs() from the kmalloc-64 slab, as nbufs increments past the allocated iovec entries. BUG: KASAN: slab-out-of-bounds in io_bundle_nbufs+0x128/0x160 Read of size 8 at addr ffff888100ae05c8 by task exp/145 Call Trace: io_bundle_nbufs+0x128/0x160 io_recv_finish+0x117/0xe20 io_recv+0x2db/0x1160 Fix this by rejecting negative sr->len values early in both io_sendmsg_prep() and io_recvmsg_prep(). Since sqe->len is __u32, any value > INT_MAX indicates overflow and is not a valid length. | |||||
| CVE-2026-31775 | 1 Linux | 1 Linux Kernel | 2026-05-07 | N/A | 5.5 MEDIUM |
| In the Linux kernel, the following vulnerability has been resolved: ALSA: ctxfi: Don't enumerate SPDIF1 at DAIO initialization The recent refactoring of xfi driver changed the assignment of atc->daios[] at atc_get_resources(); now it loops over all enum DAIOTYP entries while it looped formerly only a part of them. The problem is that the last entry, SPDIF1, is a special type that is used only for hw20k1 CTSB073X model (as a replacement of SPDIFIO), and there is no corresponding definition for hw20k2. Due to the lack of the info, it caused a kernel crash on hw20k2, which was already worked around by the commit b045ab3dff97 ("ALSA: ctxfi: Fix missing SPDIFI1 index handling"). This patch addresses the root cause of the regression above properly, simply by skipping the incorrect SPDIF1 type in the parser loop. For making the change clearer, the code is slightly arranged, too. | |||||
| CVE-2026-31776 | 1 Linux | 1 Linux Kernel | 2026-05-07 | N/A | 7.8 HIGH |
| In the Linux kernel, the following vulnerability has been resolved: ALSA: ctxfi: Fix missing SPDIFI1 index handling SPDIF1 DAIO type isn't properly handled in daio_device_index() for hw20k2, and it returned -EINVAL, which ended up with the out-of-bounds array access. Follow the hw20k1 pattern and return the proper index for this type, too. | |||||
| CVE-2026-31777 | 1 Linux | 1 Linux Kernel | 2026-05-07 | N/A | 5.5 MEDIUM |
| In the Linux kernel, the following vulnerability has been resolved: ALSA: ctxfi: Check the error for index mapping The ctxfi driver blindly assumed a proper value returned from daio_device_index(), but it's not always true. Add a proper error check to deal with the error from the function. | |||||