Export limit exceeded: 54328 CVEs match your query. Please refine your search to export 10,000 CVEs or fewer.

Search

Search Results (54328 CVEs found)

CVE Vendors Products Updated CVSS v3.1
CVE-2026-12309 1 Mozilla 2 Firefox, Thunderbird 2026-10-21 6.5 Medium
Memory safety bug fixed in Thunderbird 152. This vulnerability was fixed in Firefox 152, Firefox ESR 140.12, Thunderbird 152, and Thunderbird 140.12.
CVE-2026-12308 1 Mozilla 2 Firefox, Thunderbird 2026-10-21 5.3 Medium
Memory safety bug fixed in Thunderbird 152. This vulnerability was fixed in Firefox 152, Firefox ESR 140.12, Thunderbird 152, and Thunderbird 140.12.
CVE-2026-12307 1 Mozilla 2 Firefox, Thunderbird 2026-10-21 5.3 Medium
Memory safety bug fixed in Thunderbird 152. This vulnerability was fixed in Firefox 152, Firefox ESR 140.12, Thunderbird 152, and Thunderbird 140.12.
CVE-2026-12306 1 Mozilla 2 Firefox, Thunderbird 2026-10-21 5.3 Medium
Memory safety bug fixed in Thunderbird 152. This vulnerability was fixed in Firefox 152, Firefox ESR 140.12, Thunderbird 152, and Thunderbird 140.12.
CVE-2026-12305 1 Mozilla 2 Firefox, Thunderbird 2026-10-21 7.5 High
Memory safety bug fixed in Thunderbird 152. This vulnerability was fixed in Firefox 152, Firefox ESR 140.12, Thunderbird 152, and Thunderbird 140.12.
CVE-2026-12301 1 Mozilla 2 Firefox, Thunderbird 2026-10-21 5.3 Medium
Memory safety bug fixed in Thunderbird 152. This vulnerability was fixed in Firefox 152 and Thunderbird 152.
CVE-2026-12300 1 Mozilla 2 Firefox, Thunderbird 2026-10-21 5.3 Medium
Memory safety bug fixed in Thunderbird 152. This vulnerability was fixed in Firefox 152 and Thunderbird 152.
CVE-2026-12298 1 Mozilla 2 Firefox, Thunderbird 2026-10-21 5.4 Medium
Memory safety bug fixed in Thunderbird 152. This vulnerability was fixed in Firefox 152, Firefox ESR 140.12, Thunderbird 152, and Thunderbird 140.12.
CVE-2026-12290 1 Mozilla 2 Firefox, Thunderbird 2026-10-21 8.1 High
Memory safety bug fixed in Thunderbird 152. This vulnerability was fixed in Firefox 152, Firefox ESR 140.12, Firefox ESR 115.37, Thunderbird 152, and Thunderbird 140.12.
CVE-2026-16360 1 Mozilla 2 Firefox, Thunderbird 2026-10-21 9.8 Critical
Memory safety bugs present in Thunderbird ESR 140.12 and Thunderbird 152. Some of these bugs showed evidence of memory corruption and we presume that with enough effort some of these could have been exploited to run arbitrary code. This vulnerability was fixed in Firefox 153, Firefox ESR 115.38, Firefox ESR 140.13, Thunderbird 153, and Thunderbird 140.13.
CVE-2026-16412 1 Mozilla 1 Firefox 2026-10-21 9.8 Critical
Memory safety bugs present in Thunderbird ESR 140.12 and Thunderbird 152. Some of these bugs showed evidence of memory corruption and we presume that with enough effort some of these could have been exploited to run arbitrary code. This vulnerability was fixed in Firefox 153, Firefox ESR 140.13, Thunderbird 153, and Thunderbird 140.13.
CVE-2026-8092 1 Mozilla 2 Firefox, Thunderbird 2026-10-21 8.1 High
Memory safety bugs present in Thunderbird ESR 140.10.1 and Thunderbird 150.0.1. Some of these bugs showed evidence of memory corruption and we presume that with enough effort some of these could have been exploited to run arbitrary code. This vulnerability was fixed in Firefox 150.0.2, Firefox ESR 140.10.2, Firefox ESR 115.35.2, Thunderbird 150.0.2, and Thunderbird 140.10.2.
CVE-2026-83881 1 Microsoft 28 Windows 10 1607, Windows 10 1809, Windows 10 21h2 and 25 more 2026-10-21 7.8 High
Heap-based buffer overflow in Windows exFAT File System allows an authorized attacker to elevate privileges locally.
CVE-2025-23133 1 Linux 1 Linux Kernel 2026-10-21 8.8 High
In the Linux kernel, the following vulnerability has been resolved: wifi: ath11k: update channel list in reg notifier instead reg worker Currently when ath11k gets a new channel list, it will be processed according to the following steps: 1. update new channel list to cfg80211 and queue reg_work. 2. cfg80211 handles new channel list during reg_work. 3. update cfg80211's handled channel list to firmware by ath11k_reg_update_chan_list(). But ath11k will immediately execute step 3 after reg_work is just queued. Since step 2 is asynchronous, cfg80211 may not have completed handling the new channel list, which may leading to an out-of-bounds write error: BUG: KASAN: slab-out-of-bounds in ath11k_reg_update_chan_list Call Trace: ath11k_reg_update_chan_list+0xbfe/0xfe0 [ath11k] kfree+0x109/0x3a0 ath11k_regd_update+0x1cf/0x350 [ath11k] ath11k_regd_update_work+0x14/0x20 [ath11k] process_one_work+0xe35/0x14c0 Should ensure step 2 is completely done before executing step 3. Thus Wen raised patch[1]. When flag NL80211_REGDOM_SET_BY_DRIVER is set, cfg80211 will notify ath11k after step 2 is done. So enable the flag NL80211_REGDOM_SET_BY_DRIVER then cfg80211 will notify ath11k after step 2 is done. At this time, there will be no KASAN bug during the execution of the step 3. [1] https://patchwork.kernel.org/project/linux-wireless/patch/20230201065313.27203-1-quic_wgong@quicinc.com/ Tested-on: WCN6855 hw2.0 PCI WLAN.HSP.1.1-03125-QCAHSPSWPL_V1_V2_SILICONZ_LITE-3
CVE-2026-83888 1 Microsoft 28 Windows 10 1607, Windows 10 1809, Windows 10 21h2 and 25 more 2026-10-21 6.5 Medium
Buffer over-read in Windows CD-ROM Driver allows an unauthorized attacker to elevate privileges over a network.
CVE-2026-83895 1 Microsoft 20 Windows 10 1809, Windows 10 21h2, Windows 10 21h2 and 17 more 2026-10-21 6.8 Medium
Heap-based buffer overflow in Windows Win32 Kernel Subsystem allows an unauthorized attacker to elevate privileges with a physical attack.
CVE-2026-98168 1 Linux 1 Linux Kernel 2026-10-21 5.5 Medium
In the Linux kernel, the following vulnerability has been resolved: smb: client: fix reparse buffer bounds in cifs_query_reparse_point() In cifs_query_reparse_point(), the start >= end check before casting to struct reparse_data_buffer * only ensures the start pointer is within the response. It fails to verify that there is enough space remaining for the fixed 8-byte header of the structure. If a server provides a DataOffset that leaves less than 8 bytes remaining, the check passes, but subsequent reads of ReparseTag and ReparseDataLength will occur out-of-bounds. Fix this by ensuring the remaining space is at least the size of the reparse_data_buffer structure before accessing its fields.
CVE-2026-98085 1 Linux 1 Linux Kernel 2026-10-21 N/A
In the Linux kernel, the following vulnerability has been resolved: bpf: backtrack_insn(): Handle ld_{abs,ind} subprog exit edge Nicholas Carlini reported a bug in precision backtracking mechanism for BPF_LD | BPF_{IND,ABS} instructions. These instructions are modelled as two branches: - fallthrough; - implicit exit from current subprogram. The implicit exit case was not handled by the backtrack_insn() function. When backtracking such a path backtrack_insn() did not call bt_subprog_enter(), which meant that backtracking continued manipulating precision marks in a caller frame, while looking at instructions in a callee frame. This lead to segmentation faults during verification (see the selftest), or unsound state pruning.
CVE-2026-98053 1 Linux 1 Linux Kernel 2026-10-21 5.5 Medium
In the Linux kernel, the following vulnerability has been resolved: ASoC: Intel: avs: Refactor and fix init_config access Existing code accesses enties found in ->init_configs array through indexes that are part of ->config_ids array. Those two are limited by: ->num_init_configs and ->num_config_ids respectively. Using ID larger or equal to ->num_init_configs leads to out-of-bounds access: avs_path_module_send_init_configs() loop: (...) &acomp->tplg->init_configs[ids[i]] ^ out-of-bounds candidate Rather than adding another if-statement, refactor the code. There is no need to store the IDs, have a list of pointers to actual config-entries instead. As the verification of ->init_config entries does not differ from verification of other types that are part of the topology.c file, simply reuse the code.
CVE-2026-98041 1 Linux 1 Linux Kernel 2026-10-21 7 High
In the Linux kernel, the following vulnerability has been resolved: bpf: Don't predict JMP32 pointer vs zero comparisons Consider the following program: r1 = map_value; /* low 32 bits are zero at runtime */ r6 = 0xdead000000000000; if w1 != 0 goto l1; l0: r1 += r6; r2 = *(u64 *)(r1 + 0); exit; l1: r6 = 0; goto l0; At the moment is_branch_taken() reports the jump as always taken, because it does not distinguish between BPF_JMP and BPF_JMP32 comparisons when processing 'if w1 != 0 ...'.