Export limit exceeded: 412676 CVEs match your query. Please refine your search to export 10,000 CVEs or fewer.
Search
Search Results (412676 CVEs found)
| CVE | Vendors | Products | Updated | CVSS v3.1 |
|---|---|---|---|---|
| CVE-2026-15399 | 2 Wordpress-extensions, Wpmart | 2 Animated Number Counters, Animated Number Counters | 2026-10-18 | 4.9 Medium |
| The Animated Number Counters plugin for WordPress is vulnerable to generic SQL Injection via the 'counterid' parameter in all versions up to, and including, 3.0 due to insufficient escaping on the user supplied parameter and lack of sufficient preparation on the existing SQL query. This makes it possible for authenticated attackers, with editor-level access and above, to append additional SQL queries into already existing queries that can be used to extract sensitive information from the database. This is a second-order SQL injection: the write path correctly uses $wpdb->prepare(), but that protection is not carried forward to the read path, where the retrieved value is concatenated unsanitized into unprepared queries in both a single-quoted string context and a bare numeric context. | ||||
| CVE-2026-97815 | 1 Microsoft | 28 Windows 10 1607, Windows 10 1809, Windows 10 21h2 and 25 more | 2026-10-18 | 9.8 Critical |
| Heap-based buffer overflow in Windows Error Reporting allows an unauthorized attacker to execute code over a network. | ||||
| CVE-2026-97817 | 1 Microsoft | 28 Windows 10 1607, Windows 10 1809, Windows 10 21h2 and 25 more | 2026-10-18 | 6.5 Medium |
| Heap-based buffer overflow in DNS Server allows an authorized attacker to disclose information over a network. | ||||
| CVE-2026-92715 | 2 Themeum, Wordpress-extensions | 2 Tutor Lms – Elearning And Online Course Solution, Tutor Lms | 2026-10-18 | 4.3 Medium |
| The Tutor LMS – eLearning and online course solution plugin for WordPress is vulnerable to Insecure Direct Object Reference in all versions up to, and including, 4.1.0 via the 'ID' parameter due to missing validation on a user controlled key. This makes it possible for authenticated attackers, with author-level access and above, to modify arbitrary courses created by other instructors — overwriting their title, content, and status — and reassign ownership of those courses to themselves. This is possible because Input::sanitize_array() preserves attacker-supplied POST keys (including 'ID') without stripping them, and WordPress interprets a non-empty ID in the wp_insert_post() argument array as an update to the existing post rather than a new insert. | ||||
| CVE-2026-93515 | 1 X.org | 1 X Server | 2026-10-18 | 6.1 Medium |
| A flaw was found in xorg-x11-server. A use-after-free vulnerability, where the application accesses memory after it has already been released, occurs in the Present extension because window notification entries are not properly unlinked before cleaning up window resources. An authenticated local X client can exploit this flaw by creating cross-window notifications and subsequently destroying the target window. Successful exploitation primarily results in a Denial of Service (DoS) via an X server crash, and may potentially lead to information disclosure. | ||||
| CVE-2026-93517 | 1 X.org | 1 X Server | 2026-10-18 | 7.8 High |
| A flaw was found in xorg-x11-server. The GLX (OpenGL Extension to the X Window System) interface fails to verify that incoming data sizes do not exceed allocated buffer limits when handling large rendering requests. An authenticated local client can exploit this vulnerability by sending a specially crafted request, triggering a heap-based buffer overflow. Successful exploitation can result in arbitrary code execution with the privileges of the X server or cause a Denial of Service (DoS) by crashing the application. | ||||
| CVE-2026-93523 | 1 X.org | 1 X Server | 2026-10-18 | 7.8 High |
| A flaw was found in xorg-x11-server. A local authenticated client can exploit this flaw by sending a crafted input device ungrab request with an unvalidated modifier value. This lack of validation causes the server to perform an out-of-bounds write on the heap, resulting in memory corruption that can lead to a denial of service (DoS) or potential arbitrary code execution. | ||||
| CVE-2026-93524 | 1 X.org | 1 X Server | 2026-10-18 | 3.3 Low |
| A flaw was found in xorg-x11-server. An authenticated local user can trigger an out-of-bounds heap memory read by sending specially crafted X Keyboard Extension (XKB) requests with inconsistent key range parameters. This flaw leads to information disclosure, allowing the user to read sensitive data from the server's heap memory. | ||||
| CVE-2026-93516 | 1 X.org | 1 X Server | 2026-10-18 | 7.8 High |
| A flaw was found in xorg-x11-server. A local user can exploit a use-after-free condition—where the software attempts to access memory after it has been freed—by establishing a passive input grab and removing an input device. When subsequent input events are processed, the server dereferences the dangling device pointer. This flaw can lead to arbitrary code execution or a Denial of Service (DoS) via an X server crash. | ||||
| CVE-2026-98712 | 1 Linux | 1 Linux Kernel | 2026-10-18 | N/A |
| In the Linux kernel, the following vulnerability has been resolved: KVM: arm64: vgic: Take a refcount on IRQs referenced by last_lr_irq Referencing the last interrupt inserted in an LR is rather fragile, as this interrupt can vanish if a concurrently unmapped LPI. Solve this by bumping up the refcount on the interrupt when populating last_lr_irq, and drop it at vgic_prune_ap_list() time, when LPIs are being reclaimed. | ||||
| CVE-2026-98713 | 1 Linux | 1 Linux Kernel | 2026-10-18 | N/A |
| In the Linux kernel, the following vulnerability has been resolved: KVM: arm64: Apply the fine-grained UNDEFs without FEAT_FGT FGUs don't actually require hardware support, so don't gate fgt trap config insertion on FGT. This is the only action required to allow FGUs always, as kvm_calculate_traps() already computes the FGU bits with or without FEAT_FGT. This also fixes a spurious WARN when a TLBI OS is run on a guest in vEL1 without FEAT_TLBIOS on non FEAT_FGT hardware. In this configuration the course-grained HCR_EL2.TTLBOS trap reaches the handler handle_tlbi_el1(), which expects an EL1 TLBI only from vEL2. With FGUs enabled the UNDEF will be injected without needing the specific handler. [oliver: Take Wei-Lin's suggested changelog] | ||||
| CVE-2026-98715 | 1 Linux | 1 Linux Kernel | 2026-10-18 | N/A |
| In the Linux kernel, the following vulnerability has been resolved: KVM: SVM: Preserve TLB control (i.e. pending TLB flush) on failed VMRUN Don't reset the VMCB's TLB control back to "do nothing" on a failed VMRUN, as empirical testing shows that the CPU performs the requested TLB flush if and only if VMRUN is successful, i.e. clearing TLB control on a failed VMRUN effectively drops a TLB flush. Explicitly track the need to flush all ASIDs on a per-CPU basis, as the ASID reuse condition is tied to the pCPU, not to the vCPU. As a bonus, this also obviates the need to avoid clobbering FLUSH_ALL_ASID with TLB_CONTROL_FLUSH_ASID, e.g. in svm_flush_tlb_asid(). Deliberately don't bother saving/restoring the "old" tlb_ctl on failure, in quotes because it's not exactly the old tlb_ctl, it's the tlb_ctl from after pre_svm_run(), but before updating tlb_ctl for flush_all_asids. If VMRUN fails and TLB_CONTROL_FLUSH_ALL_ASID is forced, then the next successful run of the VMCB *may* unnecessarily flush all ASIDs, which strictly speaking could result in noisy neighbor issues. However, the fact that new_asid() is already guest-triggerable, because of KVM's flawed behavior of clearing the ASID on emulated INIT, means that a guest can already trigger a flush of all ASIDs at roughly the same rate. And once KVM stops clobbering the ASID on emulated INIT, *or* assigns a static ASID to each vCPU, this flaw goes away. | ||||
| CVE-2026-98718 | 1 Linux | 1 Linux Kernel | 2026-10-18 | N/A |
| In the Linux kernel, the following vulnerability has been resolved: KVM: SEV: Do cache maintenance on the source VM *before* clearing SEV state Explicitly flush caches after intra-host migration before clearing "SEV active" on the source VM, as doing cache maintenance afterwards creates a tiny window where memory reclaim could return memory to the host without performing a cache flush, e.g. as pointed out by Sashiko: CPU1 in sev_migrate_from(): src->active = false; CPU2 running concurrent unmap: Since active is false, the automatic cache flush in sev_guest_memory_reclaimed is skipped. The host frees and reallocates the page. CPU1 in sev_migrate_from(): sev_writeback_caches(src_kvm); Executes a hardware cache flush (wbnoinvd), which writes the guest's old dirty ciphertext over the new page owner's data. | ||||
| CVE-2026-98720 | 1 Linux | 1 Linux Kernel | 2026-10-18 | N/A |
| In the Linux kernel, the following vulnerability has been resolved: KVM: nVMX: Force MSR bitmap refresh if runtime eVMCS controls are modified Force a refresh of the vmcs02 MSR bitmap during nested VM-Enter if the runtime eVMCS controls (pin, primary, secondary, etc.) are being updated. If L1 isn't intercepting TPR writes, runs L2 with TPR virtualization, and then runs the same L2 with TPR virtualization disabled, KVM will fail to refresh msr_bitmap02 and leave TPR in passthrough mode even though TPR virtualization is disabled. I.e. failure to refresh the bitmap lets L2 (or L1 by proxy) read and write L0's TPR. | ||||
| CVE-2026-98724 | 1 Linux | 1 Linux Kernel | 2026-10-18 | N/A |
| In the Linux kernel, the following vulnerability has been resolved: nvmet: pci-epf: reject too-short SGL segments The host controls an SGL segment's length. A nonzero length smaller than one SGL descriptor makes nr_descs zero, so nvmet_pci_epf_get_sgl_segment() reads the type byte of sgls[-1] outside the allocated buffer. If that byte contains a segment descriptor type, the function also copies the preceding 16 bytes and returns a negative descriptor count. The read was reproduced in 3/3 KASAN boots with only the host transfer mocked by a KUnit test: BUG: KASAN: slab-out-of-bounds in nvmet_pci_epf_get_sgl_segment Read of size 1 by task kunit_try_catch Call Trace: nvmet_pci_epf_get_sgl_segment nvmet_pci_epf_short_sgl_test Kernel panic - not syncing: KASAN: panic_on_warn set ... Reject segments that cannot hold one descriptor before allocating or transferring their contents. | ||||
| CVE-2026-97820 | 1 Microsoft | 28 Windows 10 1607, Windows 10 1809, Windows 10 21h2 and 25 more | 2026-10-18 | 6.5 Medium |
| Out-of-bounds read in DNS Server allows an authorized attacker to disclose information over a network. | ||||
| CVE-2026-97825 | 1 Microsoft | 23 Windows 10 1607, Windows 10 1809, Windows 10 21h2 and 20 more | 2026-10-18 | 6.5 Medium |
| Out-of-bounds read in DNS Server allows an authorized attacker to disclose information over a network. | ||||
| CVE-2026-98641 | 1 Linux | 1 Linux Kernel | 2026-10-18 | N/A |
| In the Linux kernel, the following vulnerability has been resolved: bpf, arm64: set up the frame pointer for the exception callback A program acting as exception boundary saves all callee-saved registers, so build_prologue() takes the exception_cb path and never calls push_callee_regs(). That is the only place find_used_callee_regs() runs, and with it the only place ctx->fp_used is set, so the callback prologue does not emit the mov x25, sp that points BPF_REG_FP at the frame the callback runs on. x25 keeps whatever it held when bpf_throw() was called. If the throw came from a subprogram that uses its own BPF stack, that is the subprogram's frame pointer, and since the subprogram never returns it never restores x25 either. Stack accesses through BPF_REG_FP are rewritten to be stack pointer relative, so those still land in the callback's own frame. Materializing the register does not: a callback that passes the address of a local variable to a helper hands over an address in the dead subprogram's frame. That address is below the callback's stack pointer by then, and the helper's own call chain covers it, so the helper can write over its own return address. 0x1234 below is the value the helper was asked to store: pc : 0x1234 lr : 0x1234 Call trace: 0x1234 (P) bpf_test_run+0x188/0x3e0 bpf_prog_test_run_skb+0x47c/0x998 __sys_bpf+0xbdc/0xdd8 Kernel panic - not syncing: Oops: Fatal exception in interrupt Set ctx->fp_used on the exception callback path so that the existing code further down sets x25 from the stack pointer. The epilogue restores it from the main program's save area along with the other callee-saved registers, as it already does. x86 sets the frame pointer for the callback from the argument it is passed, and powerpc computes it from the stack pointer. | ||||
| CVE-2026-98643 | 1 Linux | 1 Linux Kernel | 2026-10-18 | N/A |
| In the Linux kernel, the following vulnerability has been resolved: bpf: Fix out-of-bounds read of rtt_min in sock_ops A sockops prog reading skops->rtt_min never checks the sk type: on the tcp_conn_request() path sock_ops->sk is a request_sock (non-full), and the ctx rewrite casts it to a tcp_sock (full) and reads rtt_min past the end of the request_sock, returning dirty adjacent memory. SEC("sockops") int prog(struct bpf_sock_ops *skops) { switch (skops->op) { case BPF_SOCK_OPS_RWND_INIT: leak = skops->rtt_min; /* reads the request_sock OOB */ ... } } For instance one such read returned rtt_min=0xffff8881, the high half of a leaked kernel pointer. Guarding that cast is exactly what SOCK_OPS_GET_FIELD() does -- it checks is_locked_tcp_sock and returns 0 when sock_ops->sk is not a locked full socket. Every other tcp_sock field in sock_ops goes through it; rtt_min is the only one open-coded, so it skips the check. Read rtt_min through SOCK_OPS_GET_FIELD() too. rtt_min is a bit special: it is a struct minmax and we only want the current min, so pass rtt_min.s[0].v. That is equivalent to the old hand-computed offset offsetof(struct tcp_sock, rtt_min) + sizeof_field(struct minmax_sample, t) (s[0] sits at rtt_min + 0 and .v at + sizeof(.t), i.e. what minmax_get() returns), so the loaded field is unchanged and only the full-sock guard is added. The two BUILD_BUG_ON()s that protected the hand-computed offset are no longer needed. Before patch: 0: r1 = *(u64 *)(r1 +0) ; r1 = skops->sk 1: r1 = *(u32 *)(r1 +2324) ; ((tcp_sock *)sk)->rtt_min.s[0].v After patch: 0: *(u64 *)(r1 +56) = r9 1: r9 = *(u8 *)(r1 +50) ; is_locked_tcp_sock 2: if r9 == 0 goto pc+4 ; not a locked full sock -> 0 3: r9 = *(u64 *)(r1 +56) 4: r1 = *(u64 *)(r1 +0) ; r1 = skops->sk 5: r1 = *(u32 *)(r1 +2324) ; rtt_min.s[0].v 6: goto pc+2 7: r9 = *(u64 *)(r1 +56) 8: r1 = 0 | ||||
| CVE-2026-98644 | 1 Linux | 1 Linux Kernel | 2026-10-18 | N/A |
| In the Linux kernel, the following vulnerability has been resolved: bpf: Avoid soft lockup in __htab_map_lookup_and_delete_batch() __htab_map_lookup_and_delete_batch() has no rescheduling point. The batch count bounds how many entries are copied out, not how many buckets are visited, so one BPF_MAP_LOOKUP_BATCH call can walk the map end to end. The empty-bucket fast path is worse: it stays inside a single rcu_read_lock() / bpf_disable_instrumentation() section for any run of consecutive empty buckets. That holds up on small maps, but it falls apart at scale. On a 144-CPU arm64 host running a CONFIG_PREEMPT_NONE kernel, periodic BPF_MAP_LOOKUP_BATCH calls against an LRU hash map with 16,777,216 buckets held a CPU inside the batch op for 77+ seconds and triggered the soft lockup watchdog. Commit 75134f16e7dd ("bpf: Add schedule points in batch ops") fixed this same problem in the generic batch ops, but not in this htab-native path, which every htab-based hash map variant uses for its lookup[_and_delete] batch ops. Complete that fix here. Leave the critical section after 64 consecutive empty buckets, call cond_resched_tasks_rcu_qs(), and resume at the saved bucket cursor. No locks are held at that point, and resuming from the cursor is already the function's behavior for non-empty buckets. Add the same call to the per-bucket loop after copy_to_user(), where every lock has been dropped. cond_resched_rcu() is not enough here: sleeping with bpf_prog_active elevated makes tracing programs on that CPU silently skip their invocations. Plain cond_resched() is not enough either. It is a no-op under PREEMPT and PREEMPT_LAZY, the only models arm64 and x86 have offered since commit 7dadeaa6e851 ("sched: Further restrict the preemption modes"). It is also never a Tasks RCU quiescent state, in any model: the reschedule counts as a preemption. The walking task stays a holdout and stalls every synchronize_rcu_tasks() caller, ftrace and BPF trampoline teardown included, until the syscall returns [1]. cond_resched_tasks_rcu_qs() is the usual tool for that [2]. It reports the quiescent state at each yield and still reschedules as cond_resched() does on PREEMPT_NONE and PREEMPT_VOLUNTARY kernels. | ||||