Export limit exceeded: 408506 CVEs match your query. Please refine your search to export 10,000 CVEs or fewer.
Search
Search Results (408506 CVEs found)
| CVE | Vendors | Products | Updated | CVSS v3.1 |
|---|---|---|---|---|
| CVE-2026-110909 | 2026-10-15 | 5 Medium | ||
| Wheels CLI through 4.1.0 does not verify that the local development server answering its HTTP requests belongs to the current project. A process listening on a port targeted by the CLI can receive the project's reload password and code submitted through wheels reload or wheels console; console also probes common ports when the project server is down. Other commands can perform unintended state-changing operations against a different local application's server and database. Exploitation requires a process listening on a targeted local port and the developer running an affected command. This is fixed in 4.1.1, including changes to the CLI and application template. | ||||
| CVE-2026-93484 | 1 Znuny | 1 Znuny | 2026-10-15 | N/A |
| Znuny through 7.3.6 constructs a ticket-search database query by directly concatenating user-supplied input into the SQL statement. This lack of proper sanitization or the use of parameterized queries allows an attacker to inject arbitrary SQL commands, leading to data theft, modification, or denial of service. Specifically this is in Kernel::System::Ticket::TicketSearch and Kernel::System::Ticket::ArticleSearchIndex::DB via the ContentSearch parameter. The parameter is expected to be either "AND" or "OR", but its value was concatenated directly into the generated SQL query without validation. | ||||
| CVE-2026-109145 | 2026-10-15 | 9.8 Critical | ||
| The User Rights Access Manager WordPress plugin through 1.1.3 does not restrict access to one of its AJAX account-registration handlers and assigns newly registered accounts a role that was created as a copy of the administrator role, allowing unauthenticated attackers to register an administrator-equivalent account and take over the site. | ||||
| CVE-2026-74920 | 2026-10-15 | 7.1 High | ||
| The Document Gallery WordPress plugin through 5.1.1 does not properly sanitise and escape user input before reflecting it inside an HTML attribute in the response of an unauthenticated AJAX action, leading to a Reflected Cross-Site Scripting vulnerability which can be exploited against any visitor, including a logged-in administrator. | ||||
| CVE-2026-37107 | 1 Danpros | 1 Htmly | 2026-10-15 | 9.8 Critical |
| An issue in HTMLy v.3.1.1 allows a remote attacker to escalate privileges via the get_feed function in the admin.php component | ||||
| CVE-2026-108400 | 1 Microsoft | 4 Hevc Video Extensions, Hevc Video Extensions For Licensed Applications, Hevc Video Extensions For Licensed Appplications and 1 more | 2026-10-15 | 8.8 High |
| Integer overflow or wraparound in Microsoft Windows Codecs Library allows an unauthorized attacker to execute code over a network. | ||||
| CVE-2026-98375 | 1 Linux | 1 Linux Kernel | 2026-10-15 | 7.0 High |
| In the Linux kernel, the following vulnerability has been resolved: xen/netfront: drop RX packets with a short Ethernet header handle_incoming_queue() pulls pull_to bytes into the head before calling eth_type_trans(). pull_to is the length of the first RX slot, capped at RX_COPY_THRESHOLD, and that length comes from the backend. Nothing checks it against ETH_HLEN. If the first slot is shorter than ETH_HLEN and more slots follow, the head ends up shorter than an Ethernet header while skb->len is longer, and eth_type_trans() BUG()s in __skb_pull(). If the whole packet is shorter than ETH_HLEN, eth_type_trans() reads the header past the end of the data instead. Pull at least ETH_HLEN, and drop the packet if that fails, which also drops packets too short to hold an Ethernet header. This also checks the return value of the pull, which was ignored. | ||||
| CVE-2026-98162 | 1 Linux | 1 Linux Kernel | 2026-10-15 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: smb/server: fix tree connection leak in smb2_tree_connect() See the procedure below: smb2_tree_connect ksmbd_tree_conn_connect xa_store(&sess->tree_conns, tree_conn->id, tree_conn) ksmbd_counter_inc(KSMBD_COUNTER_TREE_CONNS) ksmbd_share_tree_conn_inc(sc) ksmbd_iov_pin_rsp // fail status.ret = KSMBD_TREE_CONN_STATUS_NOMEM // do not disconnect tree_conn Disconnect the new tree connection if ksmbd_iov_pin_rsp() fails. | ||||
| CVE-2026-98147 | 1 Linux | 1 Linux Kernel | 2026-10-15 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: printk: Don't WARN on kthread_run failure. Since __kthread_create_on_node() returns -EINTR upon SIGKILL, we should not use WARN_ON() in order to catch kthread_run() failure. | ||||
| CVE-2026-98134 | 1 Linux | 1 Linux Kernel | 2026-10-15 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: bpf: check_cond_jmp_op(): properly infer if register is null Nicholas Carlini reported a bug when verifier can incorrectly infer that a pointer is non-null. The bug occurs when two pointers are compared and one of them has a type w/o PTR_MAYBE_NULL flag, but which allows a value to be NULL at runtime. Here is an example: // `a` is PTR_TO_MEM | MEM_RDONLY | PTR_UNTRUSTED // `a` is 0 at runtime. // `b` is PTR_TO_MAP_VALUE | PTR_MAYBE_NULL void *a = bpf_rdonly_cast(0, 0); int *b = bpf_map_lookup_elem(...); if (a == b) *b = 42; // verifier does not catch null pointer dereference This happens because of a special case in check_cond_jmp_op(), which attempts to strip PTR_MAYBE_NULL flags from pointer types, when processing comparisons like `rA == rB`, if either rA or rB can't be null. The non-null property is derived based on the absence of PTR_MAYBE_NULL flag on rA's or rB's type. But that is not sufficient for types like PTR_TO_MEM, as in the example. This patch replaces type_may_be_null() call with reg_not_null(), which contains an allowlist of types for which absence of PTR_MAYBE_NULL actually means that the value can't be NULL at runtime. At the moment, the list in the reg_not_null() omits two types for which PTR_MAYBE_NULL is applicable: PTR_TO_XDP_SOCK and PTR_TO_BUF. In order to remain backward compatible, and assuming that only comparison between pointers of the same type makes sense, this commit extends reg_not_null(). W/o such an extension e.g. verifier_jeq_infer_not_null/null_ptr_to_map_value fails. reg_not_null() can be extended further, but I deem that out of scope for the fix at hand. Explicit base_type(...) != PTR_TO_BTF_ID checks in the check_cond_jmp_op() can be removed with migration to reg_not_null(), but that is a behavioural change, as the special case would start matching for PTR_TO_BTF_ID that is also is_trusted_reg(). I omit the behavioural change from this commit. | ||||
| CVE-2026-98131 | 1 Linux | 1 Linux Kernel | 2026-10-15 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: net: stmmac: fix dma mapping leak in stmmac_tso_xmit() In stmmac_tso_xmit(), if the DMA mapping of an skb fragment fails, the frame is dropped but the DMA mappings already created for the linear part and for the fragments mapped before the failure are never unmapped, leaking DMA mappings. Fix the leak by walking back over the descriptors used by the frame and releasing each of them with stmmac_free_tx_buffer(). Moreover, release the descriptors with stmmac_release_tx_desc() unmapping the DMA buffers. | ||||
| CVE-2026-98099 | 1 Linux | 1 Linux Kernel | 2026-10-15 | N/A |
| In the Linux kernel, the following vulnerability has been resolved: ipv6: mcast: use rcu_assign_pointer() for __rcu list updates Several places in net/ipv6/mcast.c update RCU-protected lists (np->ipv6_mc_list, idev->mc_list, idev->mc_tomb) using direct pointer assignments instead of rcu_assign_pointer(): 1. In __ipv6_dev_mc_dec(), unlinking a group from idev->mc_list did: *map = ma->next; without rcu_assign_pointer() while concurrent readers traverse idev->mc_list locklessly under rcu_read_lock(). 2. In ipv6_sock_mc_drop() and __ipv6_sock_mc_close(), unlinking a group from np->ipv6_mc_list directly assigned *lnk = mc_lst->next and np->ipv6_mc_list = mc_lst->next without rcu_assign_pointer(), racing with lockless readers in inet6_mc_check(). 3. In __ipv6_sock_mc_join(), mc_lst->next was initialized to np->ipv6_mc_list via raw assignment before publishing mc_lst. 4. In mld_del_delrec() and __ipv6_dev_mc_inc(), __rcu source pointers passed into rcu_assign_pointer() lacked explicit dereference helpers. Fix these by consistently using rcu_assign_pointer() along with mc_dereference() / sock_dereference(). | ||||
| CVE-2026-98085 | 1 Linux | 1 Linux Kernel | 2026-10-15 | 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-98084 | 1 Linux | 1 Linux Kernel | 2026-10-15 | N/A |
| In the Linux kernel, the following vulnerability has been resolved: bpf: backtracking shouldn't clear outer frame R1-R5 for callbacks When processing calls to bpf_loop() verifier marks R1 (and R4) as precise. R1 tracks loop iterations number and because of the 'callback_depth < R1' mechanics in check_helper_call() must be marked precise. However, precision propagation for R1 was broken, when bpf_loop() call was verified on a second iteration. Consider the following verification trace: - main: bpf_loop(nr_loops, callback ...) - callback: BPF_EXIT - main: bpf_loop(nr_loops, callback ...) - ... While the first visit of the call to bpf_loop() propagated R1 precision as expected, the second call to mark_chain_precision() in the check_helper_call() set R1, but it was immediately reset when backtrack_insn() processed preceding BPF_EXIT in the loop deleted in this patch. Because of that, the second visit of the call to bpf_loop() injected checkpoint with R1 not marked as precise. Which could trick the verifier into accepting unsafe programs. See the next patch for an example of such program. Commit is structured in a way to minimize conflicts when 'bpf' would be eventually merged with 'bpf-next'. | ||||
| CVE-2026-98058 | 1 Linux | 1 Linux Kernel | 2026-10-15 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: bpf: Mark syscall helpers as sleepable bpf_sys_bpf() executes the bpf(2) syscall body, which can take mutexes, allocate with GFP_KERNEL, and wait for an RCU grace period. bpf_sys_close() reaches close_fd() and filp_close(), which can sleep as well. Both helpers are limited to BPF_PROG_TYPE_SYSCALL, whose main program is sleepable. That does not make every callback sleepable: a syscall program can register a bpf_timer callback, and the verifier checks that callback in a non-sleepable context while retaining the syscall helper set. Without .might_sleep on the prototypes, such a callback can invoke bpf_sys_bpf() from hrtimer softirq context and trigger a scheduling-while-atomic failure. bpf_sys_close() is exposed through the same missing context check. Set .might_sleep on both prototypes so the existing helper-context check rejects them from timer callbacks and other atomic regions. Calls from the sleepable main body remain valid. | ||||
| CVE-2026-98057 | 1 Linux | 1 Linux Kernel | 2026-10-15 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: ring-buffer: Add checking nr_subbufs to persistent ring buffer validation Sashiko reported that the code was using meta->nr_subbufs without making sure that it matched the nr_pages + 1 on data that was assuming the two were the same. Add a check to the persistent ring buffer validation code to make sure that the saved nr_subbufs matches what we expect. | ||||
| CVE-2026-98049 | 1 Linux | 1 Linux Kernel | 2026-10-15 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: bpf: zero extend the result of an arena 32-bit cmpxchg bpf_convert_ctx_accesses() rewrites an atomic on an arena pointer from BPF_STX | BPF_ATOMIC to BPF_STX | BPF_PROBE_ATOMIC, and it runs before bpf_opt_subreg_zext_lo32_rnd_hi32(). That pass emits an explicit zero extension for a 32-bit cmpxchg even when bpf_jit_needs_zext() is false. This is done because on some architectures 32-bit cmpxchg requires explicit zero extension for the dst register. E.g. on x86-64 'lock cmpxchg' does not change the %eax if comparison is successful, while BPF semantics declare that each operation on a 32-bit register zero extends it's upper half. is_cmpxchg_insn() matches BPF_MODE == BPF_ATOMIC only, so an arena cmpxchg misses said zero extension adjustment. This patch adjusts is_cmpxchg_insn() to match BPF_PROBE_ATOMIC alongside BPF_ATOMIC. | ||||
| CVE-2026-98048 | 1 Linux | 1 Linux Kernel | 2026-10-15 | 7.0 High |
| In the Linux kernel, the following vulnerability has been resolved: bpf: don't rewrite bpf_fastcall patterns entered by a jump mark_fastcall_pattern_for_call() must ensure that matched "spill; call; fill" instruction series is not interrupted by a jump. Otherwise the rewrite applied by bpf_remove_fastcall_spills_fills() is not sound. Record the instructions targeted by jumps in insn_aux_data[*].jump_target when the CFG is built and use this flag to stop growing a pattern at such an instruction. Jumps to the first spill are fine. Note that existing insn_aux_data[*].jmp_point field can't be reused, as it marks subprogram return instructions. | ||||
| CVE-2026-98043 | 1 Linux | 1 Linux Kernel | 2026-10-15 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: bpf: Don't infer non-NULL from a pointer with an unbounded offset reg_not_null() decides that a register holds a non-NULL value by looking at its type alone. For pointer types that allow arithmetic the type only guarantees a non-NULL base, in case of an unbound offset the runtime offset value might still add up to NULL. Consider the followng program: r6 = bpf_map_lookup_elem(map, &0); /* present */ if (r6 == 0) return 0; r7 = bpf_map_lookup_elem(map, &1); /* absent, NULL at runtime */ r8 = r7; r8 -= r6; /* pointer - pointer: unknown scalar, -r6 */ r8 <<= 1; r8 >>= 1; /* any non-negative offset is accepted by */ /* check_reg_sane_offset_ptr() */ r6 += r8; /* verifier: map value; runtime: zero */ if (r7 != r6) return 0; *(u8 *)(r7 + 0); /* r7 is inferred non-NULL, both are zero */ At runtime both registers are zero, the comparison is true and the load faults with NULL pointer dereference. Require the offset to be within +-BPF_MAX_VAR_OFF in reg_not_null(). | ||||
| CVE-2026-98038 | 1 Linux | 1 Linux Kernel | 2026-10-15 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: bpf: Keep refcount_acquire nullable for borrowed RCU kptrs bpf_refcount_acquire() is fallible for a borrowed reference because the object may have reached a zero refcount. The verifier therefore keeps KF_RET_NULL on the return value unless the argument is an owning reference. An RCU-protected load of a local kptr is marked MEM_ALLOC, but it only receives NON_OWN_REF when the pointee contains a graph node. A refcounted object without a graph node consequently looks like an owning reference even though the loaded register has no acquired reference state. If the program drops the last real reference while remaining in the RCU critical section, refcount_inc_not_zero() returns NULL while the verifier treats the result as non-NULL. Only classify the argument as owning when it is backed by a verifier-tracked reference. This retains the non-NULL return for pointers from bpf_obj_new(), bpf_kptr_xchg(), or an earlier successful acquisition, while requiring a NULL check for borrowed RCU kptrs. [ kkd: Rewrote commit log ] | ||||