Export limit exceeded: 352540 CVEs match your query. Please refine your search to export 10,000 CVEs or fewer.
Search
Search Results (8423 CVEs found)
| CVE | Vendors | Products | Updated | CVSS v3.1 |
|---|---|---|---|---|
| CVE-2026-28799 | 1 Pjsip | 2 Pjproject, Pjsip | 2026-04-16 | 7.5 High |
| PJSIP is a free and open source multimedia communication library written in C. Prior to version 2.17, a heap use-after-free vulnerability exists in PJSIP's event subscription framework (evsub.c) that is triggered during presence unsubscription (SUBSCRIBE with Expires=0). This issue has been patched in version 2.17. | ||||
| CVE-2026-28687 | 1 Imagemagick | 1 Imagemagick | 2026-04-16 | 5.3 Medium |
| ImageMagick is free and open-source software used for editing and manipulating digital images. Prior to versions 7.1.2-16 and 6.9.13-41, a heap use-after-free vulnerability in ImageMagick's MSL decoder allows an attacker to trigger access to freed memory by crafting an MSL file. This vulnerability is fixed in 7.1.2-16 and 6.9.13-41. | ||||
| CVE-2026-26311 | 1 Envoyproxy | 1 Envoy | 2026-04-16 | 5.9 Medium |
| Envoy is a high-performance edge/middle/service proxy. Prior to 1.37.1, 1.36.5, 1.35.8, and 1.34.13, a logic vulnerability in Envoy's HTTP connection manager (FilterManager) that allows for Zombie Stream Filter Execution. This issue creates a "Use-After-Free" (UAF) or state-corruption window where filter callbacks are invoked on an HTTP stream that has already been logically reset and cleaned up. The vulnerability resides in source/common/http/filter_manager.cc within the FilterManager::decodeData method. The ActiveStream object remains valid in memory during the deferred deletion window. If a DATA frame arrives on this stream immediately after the reset (e.g., in the same packet processing cycle), the HTTP/2 codec invokes ActiveStream::decodeData, which cascades to FilterManager::decodeData. FilterManager::decodeData fails to check the saw_downstream_reset_ flag. It iterates over the decoder_filters_ list and invokes decodeData() on filters that have already received onDestroy(). This vulnerability is fixed in 1.37.1, 1.36.5, 1.35.8, and 1.34.13. | ||||
| CVE-2026-3918 | 4 Apple, Google, Linux and 1 more | 4 Macos, Chrome, Linux Kernel and 1 more | 2026-04-16 | 8.8 High |
| Use after free in WebMCP in Google Chrome prior to 146.0.7680.71 allowed a remote attacker to potentially exploit heap corruption via a crafted HTML page. (Chromium security severity: High) | ||||
| CVE-2026-20822 | 1 Microsoft | 18 Windows 10 1607, Windows 10 1809, Windows 10 21h2 and 15 more | 2026-04-16 | 7.8 High |
| Use after free in Microsoft Graphics Component allows an authorized attacker to elevate privileges locally. | ||||
| CVE-2026-20832 | 1 Microsoft | 18 Windows 10 1607, Windows 10 1809, Windows 10 21h2 and 15 more | 2026-04-16 | 7.8 High |
| Windows Remote Procedure Call Interface Definition Language (IDL) Elevation of Privilege Vulnerability | ||||
| CVE-2026-20842 | 1 Microsoft | 14 Windows 10 21h2, Windows 10 21h2, Windows 10 22h2 and 11 more | 2026-04-16 | 7 High |
| Use after free in Windows DWM allows an authorized attacker to elevate privileges locally. | ||||
| CVE-2026-20858 | 1 Microsoft | 16 Windows 10 1809, Windows 10 21h2, Windows 10 21h2 and 13 more | 2026-04-16 | 7.8 High |
| Use after free in Windows Management Services allows an authorized attacker to elevate privileges locally. | ||||
| CVE-2026-20865 | 1 Microsoft | 16 Windows 10 1809, Windows 10 21h2, Windows 10 21h2 and 13 more | 2026-04-16 | 7.8 High |
| Use after free in Windows Management Services allows an authorized attacker to elevate privileges locally. | ||||
| CVE-2026-20918 | 1 Microsoft | 16 Windows 10 1809, Windows 10 21h2, Windows 10 21h2 and 13 more | 2026-04-16 | 7.8 High |
| Concurrent execution using shared resource with improper synchronization ('race condition') in Windows Management Services allows an authorized attacker to elevate privileges locally. | ||||
| CVE-2026-20923 | 1 Microsoft | 16 Windows 10 1809, Windows 10 21h2, Windows 10 21h2 and 13 more | 2026-04-16 | 7.8 High |
| Use after free in Windows Management Services allows an authorized attacker to elevate privileges locally. | ||||
| CVE-2026-20924 | 1 Microsoft | 16 Windows 10 1809, Windows 10 21h2, Windows 10 21h2 and 13 more | 2026-04-16 | 7.8 High |
| Use after free in Windows Management Services allows an authorized attacker to elevate privileges locally. | ||||
| CVE-2026-21221 | 1 Microsoft | 5 Windows 11 24h2, Windows 11 24h2, Windows 11 25h2 and 2 more | 2026-04-16 | 7 High |
| Concurrent execution using shared resource with improper synchronization ('race condition') in Capability Access Management Service (camsvc) allows an authorized attacker to elevate privileges locally. | ||||
| CVE-2026-21219 | 1 Microsoft | 2 .windows Sdk, Windows Software Development Kit | 2026-04-16 | 7 High |
| Use after free in Inbox COM Objects allows an unauthorized attacker to execute code locally. | ||||
| CVE-2026-20861 | 1 Microsoft | 16 Windows 10 1809, Windows 10 21h2, Windows 10 21h2 and 13 more | 2026-04-16 | 7.8 High |
| Concurrent execution using shared resource with improper synchronization ('race condition') in Windows Management Services allows an authorized attacker to elevate privileges locally. | ||||
| CVE-2026-20873 | 1 Microsoft | 16 Windows 10 1809, Windows 10 21h2, Windows 10 21h2 and 13 more | 2026-04-16 | 7.8 High |
| Concurrent execution using shared resource with improper synchronization ('race condition') in Windows Management Services allows an authorized attacker to elevate privileges locally. | ||||
| CVE-2026-20874 | 1 Microsoft | 16 Windows 10 1809, Windows 10 21h2, Windows 10 21h2 and 13 more | 2026-04-16 | 7.8 High |
| Concurrent execution using shared resource with improper synchronization ('race condition') in Windows Management Services allows an authorized attacker to elevate privileges locally. | ||||
| CVE-2026-20411 | 2 Google, Mediatek | 26 Android, Mt6781, Mt6878 and 23 more | 2026-04-16 | 7.8 High |
| In cameraisp, there is a possible escalation of privilege due to use after free. This could lead to local denial of service if a malicious actor has already obtained the System privilege. User interaction is not needed for exploitation. Patch ID: ALPS10351676; Issue ID: MSV-5737. | ||||
| CVE-2026-23077 | 1 Linux | 1 Linux Kernel | 2026-04-16 | 7.8 High |
| In the Linux kernel, the following vulnerability has been resolved: mm/vma: fix anon_vma UAF on mremap() faulted, unfaulted merge Patch series "mm/vma: fix anon_vma UAF on mremap() faulted, unfaulted merge", v2. Commit 879bca0a2c4f ("mm/vma: fix incorrectly disallowed anonymous VMA merges") introduced the ability to merge previously unavailable VMA merge scenarios. However, it is handling merges incorrectly when it comes to mremap() of a faulted VMA adjacent to an unfaulted VMA. The issues arise in three cases: 1. Previous VMA unfaulted: copied -----| v |-----------|.............| | unfaulted |(faulted VMA)| |-----------|.............| prev 2. Next VMA unfaulted: copied -----| v |.............|-----------| |(faulted VMA)| unfaulted | |.............|-----------| next 3. Both adjacent VMAs unfaulted: copied -----| v |-----------|.............|-----------| | unfaulted |(faulted VMA)| unfaulted | |-----------|.............|-----------| prev next This series fixes each of these cases, and introduces self tests to assert that the issues are corrected. I also test a further case which was already handled, to assert that my changes continues to correctly handle it: 4. prev unfaulted, next faulted: copied -----| v |-----------|.............|-----------| | unfaulted |(faulted VMA)| faulted | |-----------|.............|-----------| prev next This bug was discovered via a syzbot report, linked to in the first patch in the series, I confirmed that this series fixes the bug. I also discovered that we are failing to check that the faulted VMA was not forked when merging a copied VMA in cases 1-3 above, an issue this series also addresses. I also added self tests to assert that this is resolved (and confirmed that the tests failed prior to this). I also cleaned up vma_expand() as part of this work, renamed vma_had_uncowed_parents() to vma_is_fork_child() as the previous name was unduly confusing, and simplified the comments around this function. This patch (of 4): Commit 879bca0a2c4f ("mm/vma: fix incorrectly disallowed anonymous VMA merges") introduced the ability to merge previously unavailable VMA merge scenarios. The key piece of logic introduced was the ability to merge a faulted VMA immediately next to an unfaulted VMA, which relies upon dup_anon_vma() to correctly handle anon_vma state. In the case of the merge of an existing VMA (that is changing properties of a VMA and then merging if those properties are shared by adjacent VMAs), dup_anon_vma() is invoked correctly. However in the case of the merge of a new VMA, a corner case peculiar to mremap() was missed. The issue is that vma_expand() only performs dup_anon_vma() if the target (the VMA that will ultimately become the merged VMA): is not the next VMA, i.e. the one that appears after the range in which the new VMA is to be established. A key insight here is that in all other cases other than mremap(), a new VMA merge either expands an existing VMA, meaning that the target VMA will be that VMA, or would have anon_vma be NULL. Specifically: * __mmap_region() - no anon_vma in place, initial mapping. * do_brk_flags() - expanding an existing VMA. * vma_merge_extend() - expanding an existing VMA. * relocate_vma_down() - no anon_vma in place, initial mapping. In addition, we are in the unique situation of needing to duplicate anon_vma state from a VMA that is neither the previous or next VMA being merged with. dup_anon_vma() deals exclusively with the target=unfaulted, src=faulted case. This leaves four possibilities, in each case where the copied VMA is faulted: 1. Previous VMA unfaulted: copied -----| ---truncated--- | ||||
| CVE-2026-23098 | 1 Linux | 1 Linux Kernel | 2026-04-16 | 8.8 High |
| In the Linux kernel, the following vulnerability has been resolved: netrom: fix double-free in nr_route_frame() In nr_route_frame(), old_skb is immediately freed without checking if nr_neigh->ax25 pointer is NULL. Therefore, if nr_neigh->ax25 is NULL, the caller function will free old_skb again, causing a double-free bug. Therefore, to prevent this, we need to modify it to check whether nr_neigh->ax25 is NULL before freeing old_skb. | ||||