Export limit exceeded: 95009 CVEs match your query. Please refine your search to export 10,000 CVEs or fewer.
Search
Search Results (95009 CVEs found)
| CVE | Vendors | Products | Updated | CVSS v3.1 |
|---|---|---|---|---|
| CVE-2021-26861 | 1 Microsoft | 19 Windows 10, Windows 10 1507, Windows 10 1607 and 16 more | 2026-08-19 | 7.8 High |
| Windows Graphics Component Remote Code Execution Vulnerability | ||||
| CVE-2021-26860 | 1 Microsoft | 9 Windows 10, Windows 10 1809, Windows 10 1909 and 6 more | 2026-08-19 | 7.8 High |
| Windows App-V Overlay Filter Elevation of Privilege Vulnerability | ||||
| CVE-2021-26859 | 1 Microsoft | 1 Power Bi Report Server | 2026-08-19 | 7.7 High |
| Microsoft Power BI Information Disclosure Vulnerability | ||||
| CVE-2021-24110 | 1 Microsoft | 2 Hevc Video Extensions, High Efficiency Video Coding | 2026-08-19 | 7.8 High |
| HEVC Video Extensions Remote Code Execution Vulnerability | ||||
| CVE-2026-68148 | 1 Linux | 1 Linux Kernel | 2026-08-19 | 7.8 High |
| In the Linux kernel, the following vulnerability has been resolved: fscrypt: Add missing superblock check in find_or_insert_direct_key() The legacy 'fscrypt_direct_keys' table caches master keys that are used by v1 encryption policies that have FSCRYPT_POLICY_FLAG_DIRECT_KEY. It's just a global table for all filesystems (since the keys can be provided by the legacy process-subscribed keyrings mechanism, which makes it difficult to reuse super_block::s_master_keys). The entries in it ('struct fscrypt_direct_key') do contain a super_block pointer, though, for passing to fscrypt_destroy_inline_crypt_key() when the last inode that references the key is evicted. However, when finding the fscrypt_direct_key for an inode, we weren't actually comparing the super_block pointer. As a result, inodes with different super_blocks could point to the same fscrypt_direct_key. That could extend the lifetime of a fscrypt_direct_key beyond the super_block it points to, causing a use-after-free later. Fix this by creating distinct fscrypt_direct_key structs for distinct super_block structs. Note that this problem doesn't exist in the v2 policy equivalent ("per-mode keys"), since the data structures there are per super_block. | ||||
| CVE-2021-24090 | 1 Microsoft | 8 Windows 10, Windows 10 1809, Windows 10 1909 and 5 more | 2026-08-19 | 7.8 High |
| Windows Error Reporting Elevation of Privilege Vulnerability | ||||
| CVE-2021-1640 | 1 Microsoft | 19 Windows 10, Windows 10 1507, Windows 10 1607 and 16 more | 2026-08-19 | 7.8 High |
| Windows Print Spooler Elevation of Privilege Vulnerability | ||||
| CVE-2021-24089 | 1 Microsoft | 2 Hevc Video Extensions, High Efficiency Video Coding | 2026-08-19 | 7.8 High |
| HEVC Video Extensions Remote Code Execution Vulnerability | ||||
| CVE-2026-68147 | 1 Linux | 1 Linux Kernel | 2026-08-19 | 7.8 High |
| In the Linux kernel, the following vulnerability has been resolved: fscrypt: Avoid dynamic allocation in fscrypt_get_devices() When a blk_crypto_key starts being used or is evicted, fs/crypto/ calls fscrypt_get_devices() to get the filesystem's list of block devices, then iterates over them and calls blk_crypto_config_supported(), blk_crypto_start_using_key(), or blk_crypto_evict_key() on each one. Currently, the block device pointers are placed in a dynamically allocated array. This dynamic allocation is problematic because: - It can fail, especially at the fscrypt_destroy_inline_crypt_key() call site when it's invoked for inode eviction under direct reclaim. - fscrypt_destroy_inline_crypt_key() doesn't handle the failure. It just zeroizes and frees the blk_crypto_key without calling blk_crypto_evict_key(). That causes a use-after-free. For now, let's fix this in the straightforward and easily-backportable way by switching to an on-stack array. Currently the fscrypt multi-device functionality is used only by f2fs, which has a hardcoded limit of 8 block devices. An on-stack array works fine for that. (Of course, this solution won't scale up to large number of block devices. For that we'd need a different solution, like moving the block device iteration into the filesystem. Or in the case of btrfs, which will only support blk-crypto-fallback, we should make it just call blk-crypto-fallback directly, so the block devices won't be needed.) | ||||
| CVE-2021-27083 | 1 Microsoft | 1 Remote Development | 2026-08-19 | 7.8 High |
| Remote Development Extension for Visual Studio Code Remote Code Execution Vulnerability | ||||
| CVE-2021-27082 | 1 Microsoft | 1 Quantum Development Kit | 2026-08-19 | 7.8 High |
| Quantum Development Kit for Visual Studio Code Remote Code Execution Vulnerability | ||||
| CVE-2021-27081 | 1 Microsoft | 2 Eslint, Visual Studio Code Eslint Extension | 2026-08-19 | 7.8 High |
| Visual Studio Code ESLint Extension Remote Code Execution Vulnerability | ||||
| CVE-2021-27077 | 1 Microsoft | 19 Windows 10, Windows 10 1507, Windows 10 1607 and 16 more | 2026-08-19 | 7.8 High |
| Windows Win32k Elevation of Privilege Vulnerability | ||||
| CVE-2021-27070 | 1 Microsoft | 6 Windows 10, Windows 10 1809, Windows 10 20h2 and 3 more | 2026-08-19 | 7.3 High |
| Windows 10 Update Assistant Elevation of Privilege Vulnerability | ||||
| CVE-2021-27060 | 1 Microsoft | 1 Visual Studio Code | 2026-08-19 | 7.8 High |
| Visual Studio Code Remote Code Execution Vulnerability | ||||
| CVE-2021-24108 | 1 Microsoft | 6 365 Apps, Excel, Office and 3 more | 2026-08-19 | 7.8 High |
| Microsoft Office Remote Code Execution Vulnerability | ||||
| CVE-2026-68143 | 1 Linux | 1 Linux Kernel | 2026-08-19 | 7.8 High |
| In the Linux kernel, the following vulnerability has been resolved: net: slip: serialize receive against buffer reallocation sl_realloc_bufs() replaces rbuff and updates buffsize while holding sl->lock. slip_receive_buf() reads those fields and writes through rbuff without holding the lock. An MTU change can therefore race with receive processing. An MTU shrink can expose the new smaller rbuff with the old larger bound, causing an out-of-bounds write. A receive callback which already loaded the old rbuff can instead continue writing after that buffer has been freed. Serialize receive processing with sl_realloc_bufs() by holding sl->lock while consuming each receive batch. | ||||
| CVE-2021-24095 | 1 Microsoft | 9 Windows 10, Windows 10 1809, Windows 10 1909 and 6 more | 2026-08-19 | 7 High |
| DirectX Elevation of Privilege Vulnerability | ||||
| CVE-2021-1729 | 1 Microsoft | 9 Windows 10, Windows 10 1809, Windows 10 1909 and 6 more | 2026-08-19 | 7.1 High |
| Windows Update Stack Setup Elevation of Privilege Vulnerability | ||||
| CVE-2026-68142 | 1 Linux | 1 Linux Kernel | 2026-08-19 | 8.8 High |
| In the Linux kernel, the following vulnerability has been resolved: geneve: require CAP_NET_ADMIN in the device netns for changelink A tunnel changelink() operates on at most two netns, dev_net(dev) and the sticky underlay netns geneve->net. They differ once the device is created in or moved to a netns other than the one the request runs in. The rtnl changelink path checks CAP_NET_ADMIN only against dev_net(dev), so a caller privileged there but not in geneve->net can rewrite a geneve device whose underlay lives in geneve->net. geneve_changelink() applies the new configuration against geneve->net: geneve_link_config() and the geneve_quiesce()/geneve_unquiesce() pair reopen the underlay sockets in that netns (geneve_sock_add() uses geneve->net), so the same reasoning as the tunnel changelink series applies here. Gate geneve_changelink() with rtnl_dev_link_net_capable(), at the top of the op before any attribute is parsed, matching ipgre_changelink() and the rest of the "require CAP_NET_ADMIN in the device netns for changelink" series. Found by 0sec automated security-research tooling (https://0sec.ai). | ||||