Export limit exceeded: 18557 CVEs match your query. Please refine your search to export 10,000 CVEs or fewer.
Search
Search Results (18557 CVEs found)
| CVE | Vendors | Products | Updated | CVSS v3.1 |
|---|---|---|---|---|
| CVE-2021-26423 | 2 Microsoft, Redhat | 7 .net, .net Core, Powershell Core and 4 more | 2026-08-10 | 7.5 High |
| .NET Core and Visual Studio Denial of Service Vulnerability | ||||
| CVE-2025-4374 | 1 Redhat | 1 Quay | 2026-08-07 | 6.5 Medium |
| A flaw was found in Quay. When an organization acts as a proxy cache, and a user or robot pulls an image that hasn't been mirrored yet, they are granted "Admin" permissions on the newly created repository. | ||||
| CVE-2026-47300 | 4 Apple, Linux, Microsoft and 1 more | 9 Macos, Linux Kernel, .net and 6 more | 2026-08-07 | 8.8 High |
| Incorrect implementation of authentication algorithm in ASP.NET Core allows an authorized attacker to elevate privileges over a network. | ||||
| CVE-2026-47302 | 4 Apple, Linux, Microsoft and 1 more | 22 Macos, Linux Kernel, .net and 19 more | 2026-08-07 | 7.5 High |
| Allocation of resources without limits or throttling in .NET allows an unauthorized attacker to deny service over a network. | ||||
| CVE-2026-47303 | 4 Apple, Linux, Microsoft and 1 more | 9 Macos, Linux Kernel, .net and 6 more | 2026-08-07 | 8.8 High |
| Authentication bypass by assumed-immutable data in ASP.NET Core allows an authorized attacker to elevate privileges over a network. | ||||
| CVE-2026-50525 | 4 Apple, Linux, Microsoft and 1 more | 21 Macos, Linux Kernel, .net and 18 more | 2026-08-05 | 7.5 High |
| Allocation of resources without limits or throttling in .NET allows an unauthorized attacker to deny service over a network. | ||||
| CVE-2026-50527 | 4 Apple, Linux, Microsoft and 1 more | 21 Macos, Linux Kernel, .net and 18 more | 2026-08-05 | 7.5 High |
| Stack-based buffer overflow in .NET Framework allows an unauthorized attacker to deny service over a network. | ||||
| CVE-2026-50646 | 2 Microsoft, Redhat | 19 .net, .net Framework, Microsoft Visual Studio 2022 and 16 more | 2026-08-05 | 7.8 High |
| Protection mechanism failure in .NET Framework allows an unauthorized attacker to execute code locally. | ||||
| CVE-2026-50648 | 4 Apple, Linux, Microsoft and 1 more | 21 Macos, Linux Kernel, .net and 18 more | 2026-08-05 | 7.5 High |
| Allocation of resources without limits or throttling in .NET Framework allows an unauthorized attacker to deny service over a network. | ||||
| CVE-2026-50650 | 2 Microsoft, Redhat | 19 .net, .net Framework, Microsoft Visual Studio 2022 and 16 more | 2026-08-05 | 7.8 High |
| Improper control of generation of code ('code injection') in .NET Framework allows an unauthorized attacker to elevate privileges locally. | ||||
| CVE-2026-50524 | 4 Apple, Linux, Microsoft and 1 more | 8 Macos, Linux Kernel, .net and 5 more | 2026-08-05 | 7.5 High |
| Improper validation of specified type of input in .NET Framework allows an unauthorized attacker to deny service over a network. | ||||
| CVE-2026-50526 | 4 Apple, Linux, Microsoft and 1 more | 8 Macos, Linux Kernel, .net and 5 more | 2026-08-05 | 7 High |
| Improper link resolution before file access ('link following') in .NET allows an authorized attacker to perform tampering locally. | ||||
| CVE-2026-50528 | 4 Apple, Linux, Microsoft and 1 more | 8 Macos, Linux Kernel, .net and 5 more | 2026-08-05 | 8.2 High |
| Incorrect authorization in .NET allows an unauthorized attacker to bypass a security feature over a network. | ||||
| CVE-2026-50649 | 2 Microsoft, Redhat | 19 .net, .net Framework, Microsoft Visual Studio 2022 and 16 more | 2026-08-05 | 7.8 High |
| Deserialization of untrusted data in .NET allows an unauthorized attacker to execute code locally. | ||||
| CVE-2026-50659 | 4 Apple, Linux, Microsoft and 1 more | 22 Macos, Linux Kernel, .net and 19 more | 2026-08-05 | 6.5 Medium |
| Improper encoding or escaping of output in .NET allows an authorized attacker to perform spoofing over a network. | ||||
| CVE-2024-56688 | 2 Linux, Redhat | 2 Linux Kernel, Enterprise Linux | 2026-08-04 | 7.5 High |
| In the Linux kernel, the following vulnerability has been resolved: sunrpc: clear XPRT_SOCK_UPD_TIMEOUT when reset transport Since transport->sock has been set to NULL during reset transport, XPRT_SOCK_UPD_TIMEOUT also needs to be cleared. Otherwise, the xs_tcp_set_socket_timeouts() may be triggered in xs_tcp_send_request() to dereference the transport->sock that has been set to NULL. | ||||
| CVE-2024-53136 | 2 Linux, Redhat | 2 Linux Kernel, Enterprise Linux | 2026-08-04 | 7.5 High |
| In the Linux kernel, the following vulnerability has been resolved: mm: revert "mm: shmem: fix data-race in shmem_getattr()" Revert d949d1d14fa2 ("mm: shmem: fix data-race in shmem_getattr()") as suggested by Chuck [1]. It is causing deadlocks when accessing tmpfs over NFS. As Hugh commented, "added just to silence a syzbot sanitizer splat: added where there has never been any practical problem". | ||||
| CVE-2024-53120 | 2 Linux, Redhat | 2 Linux Kernel, Enterprise Linux | 2026-08-04 | 7.5 High |
| In the Linux kernel, the following vulnerability has been resolved: net/mlx5e: CT: Fix null-ptr-deref in add rule err flow In error flow of mlx5_tc_ct_entry_add_rule(), in case ct_rule_add() callback returns error, zone_rule->attr is used uninitiated. Fix it to use attr which has the needed pointer value. Kernel log: BUG: kernel NULL pointer dereference, address: 0000000000000110 RIP: 0010:mlx5_tc_ct_entry_add_rule+0x2b1/0x2f0 [mlx5_core] … Call Trace: <TASK> ? __die+0x20/0x70 ? page_fault_oops+0x150/0x3e0 ? exc_page_fault+0x74/0x140 ? asm_exc_page_fault+0x22/0x30 ? mlx5_tc_ct_entry_add_rule+0x2b1/0x2f0 [mlx5_core] ? mlx5_tc_ct_entry_add_rule+0x1d5/0x2f0 [mlx5_core] mlx5_tc_ct_block_flow_offload+0xc6a/0xf90 [mlx5_core] ? nf_flow_offload_tuple+0xd8/0x190 [nf_flow_table] nf_flow_offload_tuple+0xd8/0x190 [nf_flow_table] flow_offload_work_handler+0x142/0x320 [nf_flow_table] ? finish_task_switch.isra.0+0x15b/0x2b0 process_one_work+0x16c/0x320 worker_thread+0x28c/0x3a0 ? __pfx_worker_thread+0x10/0x10 kthread+0xb8/0xf0 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x2d/0x50 ? __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1a/0x30 </TASK> | ||||
| CVE-2024-47668 | 2 Linux, Redhat | 3 Linux Kernel, Enterprise Linux, Rhel Eus | 2026-08-04 | 7.8 High |
| In the Linux kernel, the following vulnerability has been resolved: lib/generic-radix-tree.c: Fix rare race in __genradix_ptr_alloc() If we need to increase the tree depth, allocate a new node, and then race with another thread that increased the tree depth before us, we'll still have a preallocated node that might be used later. If we then use that node for a new non-root node, it'll still have a pointer to the old root instead of being zeroed - fix this by zeroing it in the cmpxchg failure path. | ||||
| CVE-2024-46828 | 2 Linux, Redhat | 2 Linux Kernel, Enterprise Linux | 2026-08-04 | 7.1 High |
| In the Linux kernel, the following vulnerability has been resolved: sched: sch_cake: fix bulk flow accounting logic for host fairness In sch_cake, we keep track of the count of active bulk flows per host, when running in dst/src host fairness mode, which is used as the round-robin weight when iterating through flows. The count of active bulk flows is updated whenever a flow changes state. This has a peculiar interaction with the hash collision handling: when a hash collision occurs (after the set-associative hashing), the state of the hash bucket is simply updated to match the new packet that collided, and if host fairness is enabled, that also means assigning new per-host state to the flow. For this reason, the bulk flow counters of the host(s) assigned to the flow are decremented, before new state is assigned (and the counters, which may not belong to the same host anymore, are incremented again). Back when this code was introduced, the host fairness mode was always enabled, so the decrement was unconditional. When the configuration flags were introduced the *increment* was made conditional, but the *decrement* was not. Which of course can lead to a spurious decrement (and associated wrap-around to U16_MAX). AFAICT, when host fairness is disabled, the decrement and wrap-around happens as soon as a hash collision occurs (which is not that common in itself, due to the set-associative hashing). However, in most cases this is harmless, as the value is only used when host fairness mode is enabled. So in order to trigger an array overflow, sch_cake has to first be configured with host fairness disabled, and while running in this mode, a hash collision has to occur to cause the overflow. Then, the qdisc has to be reconfigured to enable host fairness, which leads to the array out-of-bounds because the wrapped-around value is retained and used as an array index. It seems that syzbot managed to trigger this, which is quite impressive in its own right. This patch fixes the issue by introducing the same conditional check on decrement as is used on increment. The original bug predates the upstreaming of cake, but the commit listed in the Fixes tag touched that code, meaning that this patch won't apply before that. | ||||