Total
34599 CVE
| CVE | Vendors | Products | Updated | CVSS v3.1 |
|---|---|---|---|---|
| CVE-2025-24036 | 1 Microsoft | 1 Autoupdate | 2026-02-26 | 7 High |
| Microsoft AutoUpdate (MAU) Elevation of Privilege Vulnerability | ||||
| CVE-2025-21208 | 1 Microsoft | 11 Windows Server 2008, Windows Server 2008 R2, Windows Server 2008 Sp2 and 8 more | 2026-02-26 | 8.8 High |
| Windows Routing and Remote Access Service (RRAS) Remote Code Execution Vulnerability | ||||
| CVE-2025-21406 | 1 Microsoft | 24 Windows 10 1507, Windows 10 1607, Windows 10 1809 and 21 more | 2026-02-26 | 8.8 High |
| Windows Telephony Service Remote Code Execution Vulnerability | ||||
| CVE-2025-21407 | 1 Microsoft | 24 Windows 10 1507, Windows 10 1607, Windows 10 1809 and 21 more | 2026-02-26 | 8.8 High |
| Windows Telephony Service Remote Code Execution Vulnerability | ||||
| CVE-2025-21410 | 1 Microsoft | 11 Windows Server 2008, Windows Server 2008 R2, Windows Server 2008 Sp2 and 8 more | 2026-02-26 | 8.8 High |
| Windows Routing and Remote Access Service (RRAS) Remote Code Execution Vulnerability | ||||
| CVE-2025-21349 | 1 Microsoft | 19 Windows 10 1507, Windows 10 1607, Windows 10 1809 and 16 more | 2026-02-26 | 6.8 Medium |
| Windows Remote Desktop Configuration Service Tampering Vulnerability | ||||
| CVE-2025-0411 | 2 7-zip, Netapp | 2 7-zip, Active Iq Unified Manager | 2026-02-26 | 7.0 High |
| 7-Zip Mark-of-the-Web Bypass Vulnerability. This vulnerability allows remote attackers to bypass the Mark-of-the-Web protection mechanism on affected installations of 7-Zip. User interaction is required to exploit this vulnerability in that the target must visit a malicious page or open a malicious file. The specific flaw exists within the handling of archived files. When extracting files from a crafted archive that bears the Mark-of-the-Web, 7-Zip does not propagate the Mark-of-the-Web to the extracted files. An attacker can leverage this vulnerability to execute arbitrary code in the context of the current user. Was ZDI-CAN-25456. | ||||
| CVE-2025-21371 | 1 Microsoft | 24 Windows 10 1507, Windows 10 1607, Windows 10 1809 and 21 more | 2026-02-26 | 8.8 High |
| Windows Telephony Service Remote Code Execution Vulnerability | ||||
| CVE-2025-21386 | 1 Microsoft | 11 365 Apps, Excel, Excel 2016 and 8 more | 2026-02-26 | 7.8 High |
| Microsoft Excel Remote Code Execution Vulnerability | ||||
| CVE-2025-21387 | 1 Microsoft | 11 365 Apps, Excel, Excel 2016 and 8 more | 2026-02-26 | 7.8 High |
| Microsoft Excel Remote Code Execution Vulnerability | ||||
| CVE-2025-21390 | 1 Microsoft | 11 365 Apps, Excel, Excel 2016 and 8 more | 2026-02-26 | 7.8 High |
| Microsoft Excel Remote Code Execution Vulnerability | ||||
| CVE-2025-21392 | 1 Microsoft | 9 365 Apps, Office, Office 2016 and 6 more | 2026-02-26 | 7.8 High |
| Microsoft Office Remote Code Execution Vulnerability | ||||
| CVE-2025-21394 | 1 Microsoft | 11 365 Apps, Excel, Excel 2016 and 8 more | 2026-02-26 | 7.8 High |
| Microsoft Excel Remote Code Execution Vulnerability | ||||
| CVE-2025-21397 | 1 Microsoft | 4 365 Apps, Office 2021, Office 2024 and 1 more | 2026-02-26 | 7.8 High |
| Microsoft Office Remote Code Execution Vulnerability | ||||
| CVE-2024-12284 | 1 Citrix | 2 Netscaler Agent, Netscaler Console | 2026-02-26 | 8.8 High |
| Authenticated privilege escalation in NetScaler Console and NetScaler Agent allows. | ||||
| CVE-2025-30391 | 1 Microsoft | 1 Dynamics 365 Customer Service | 2026-02-26 | 8.1 High |
| Improper input validation in Microsoft Dynamics allows an unauthorized attacker to disclose information over a network. | ||||
| CVE-2026-22988 | 1 Linux | 1 Linux Kernel | 2026-02-26 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: arp: do not assume dev_hard_header() does not change skb->head arp_create() is the only dev_hard_header() caller making assumption about skb->head being unchanged. A recent commit broke this assumption. Initialize @arp pointer after dev_hard_header() call. | ||||
| CVE-2026-22989 | 1 Linux | 1 Linux Kernel | 2026-02-26 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: nfsd: check that server is running in unlock_filesystem If we are trying to unlock the filesystem via an administrative interface and nfsd isn't running, it crashes the server. This happens currently because nfsd4_revoke_states() access state structures (eg., conf_id_hashtbl) that has been freed as a part of the server shutdown. [ 59.465072] Call trace: [ 59.465308] nfsd4_revoke_states+0x1b4/0x898 [nfsd] (P) [ 59.465830] write_unlock_fs+0x258/0x440 [nfsd] [ 59.466278] nfsctl_transaction_write+0xb0/0x120 [nfsd] [ 59.466780] vfs_write+0x1f0/0x938 [ 59.467088] ksys_write+0xfc/0x1f8 [ 59.467395] __arm64_sys_write+0x74/0xb8 [ 59.467746] invoke_syscall.constprop.0+0xdc/0x1e8 [ 59.468177] do_el0_svc+0x154/0x1d8 [ 59.468489] el0_svc+0x40/0xe0 [ 59.468767] el0t_64_sync_handler+0xa0/0xe8 [ 59.469138] el0t_64_sync+0x1ac/0x1b0 Ensure this can't happen by taking the nfsd_mutex and checking that the server is still up, and then holding the mutex across the call to nfsd4_revoke_states(). | ||||
| CVE-2025-68358 | 1 Linux | 1 Linux Kernel | 2026-02-26 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: btrfs: fix racy bitfield write in btrfs_clear_space_info_full() From the memory-barriers.txt document regarding memory barrier ordering guarantees: (*) These guarantees do not apply to bitfields, because compilers often generate code to modify these using non-atomic read-modify-write sequences. Do not attempt to use bitfields to synchronize parallel algorithms. (*) Even in cases where bitfields are protected by locks, all fields in a given bitfield must be protected by one lock. If two fields in a given bitfield are protected by different locks, the compiler's non-atomic read-modify-write sequences can cause an update to one field to corrupt the value of an adjacent field. btrfs_space_info has a bitfield sharing an underlying word consisting of the fields full, chunk_alloc, and flush: struct btrfs_space_info { struct btrfs_fs_info * fs_info; /* 0 8 */ struct btrfs_space_info * parent; /* 8 8 */ ... int clamp; /* 172 4 */ unsigned int full:1; /* 176: 0 4 */ unsigned int chunk_alloc:1; /* 176: 1 4 */ unsigned int flush:1; /* 176: 2 4 */ ... Therefore, to be safe from parallel read-modify-writes losing a write to one of the bitfield members protected by a lock, all writes to all the bitfields must use the lock. They almost universally do, except for btrfs_clear_space_info_full() which iterates over the space_infos and writes out found->full = 0 without a lock. Imagine that we have one thread completing a transaction in which we finished deleting a block_group and are thus calling btrfs_clear_space_info_full() while simultaneously the data reclaim ticket infrastructure is running do_async_reclaim_data_space(): T1 T2 btrfs_commit_transaction btrfs_clear_space_info_full data_sinfo->full = 0 READ: full:0, chunk_alloc:0, flush:1 do_async_reclaim_data_space(data_sinfo) spin_lock(&space_info->lock); if(list_empty(tickets)) space_info->flush = 0; READ: full: 0, chunk_alloc:0, flush:1 MOD/WRITE: full: 0, chunk_alloc:0, flush:0 spin_unlock(&space_info->lock); return; MOD/WRITE: full:0, chunk_alloc:0, flush:1 and now data_sinfo->flush is 1 but the reclaim worker has exited. This breaks the invariant that flush is 0 iff there is no work queued or running. Once this invariant is violated, future allocations that go into __reserve_bytes() will add tickets to space_info->tickets but will see space_info->flush is set to 1 and not queue the work. After this, they will block forever on the resulting ticket, as it is now impossible to kick the worker again. I also confirmed by looking at the assembly of the affected kernel that it is doing RMW operations. For example, to set the flush (3rd) bit to 0, the assembly is: andb $0xfb,0x60(%rbx) and similarly for setting the full (1st) bit to 0: andb $0xfe,-0x20(%rax) So I think this is really a bug on practical systems. I have observed a number of systems in this exact state, but am currently unable to reproduce it. Rather than leaving this footgun lying around for the future, take advantage of the fact that there is room in the struct anyway, and that it is already quite large and simply change the three bitfield members to bools. This avoids writes to space_info->full having any effect on ---truncated--- | ||||
| CVE-2025-68725 | 1 Linux | 1 Linux Kernel | 2026-02-26 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: bpf: Do not let BPF test infra emit invalid GSO types to stack Yinhao et al. reported that their fuzzer tool was able to trigger a skb_warn_bad_offload() from netif_skb_features() -> gso_features_check(). When a BPF program - triggered via BPF test infra - pushes the packet to the loopback device via bpf_clone_redirect() then mentioned offload warning can be seen. GSO-related features are then rightfully disabled. We get into this situation due to convert___skb_to_skb() setting gso_segs and gso_size but not gso_type. Technically, it makes sense that this warning triggers since the GSO properties are malformed due to the gso_type. Potentially, the gso_type could be marked non-trustworthy through setting it at least to SKB_GSO_DODGY without any other specific assumptions, but that also feels wrong given we should not go further into the GSO engine in the first place. The checks were added in 121d57af308d ("gso: validate gso_type in GSO handlers") because there were malicious (syzbot) senders that combine a protocol with a non-matching gso_type. If we would want to drop such packets, gso_features_check() currently only returns feature flags via netif_skb_features(), so one location for potentially dropping such skbs could be validate_xmit_unreadable_skb(), but then otoh it would be an additional check in the fast-path for a very corner case. Given bpf_clone_redirect() is the only place where BPF test infra could emit such packets, lets reject them right there. | ||||