Export limit exceeded: 45783 CVEs match your query. Please refine your search to export 10,000 CVEs or fewer.
Search
Search Results (45783 CVEs found)
| CVE | Vendors | Products | Updated | CVSS v3.1 |
|---|---|---|---|---|
| CVE-2026-111728 | 1 5rahim | 1 Seanime | 2026-10-19 | 5.4 Medium |
| Seanime v3.7.0 to v3.10.3 contains an argument injection vulnerability reachable through improper authorization, allowing unauthenticated LAN or Tailnet clients to bypass the privileged mediastream settings guard by setting transcodeHwAccel to custom and supplying attacker-controlled decodeFlags and encodeFlags via the transcodeHwAccelCustomSettings field, which are appended verbatim to the ffmpeg argument vector. Attackers can trigger execution via the mediastream request and HLS playlist endpoints to achieve arbitrary file write and file truncation on the host as the user running seanime, with the injected input options also enabling potential arbitrary local file read and outbound data exfiltration through ffmpeg's protocol handlers. | ||||
| CVE-2026-62362 | 1 Pbh-btn | 1 Peerbanhelper | 2026-10-19 | 4.9 Medium |
| PeerBanHelper automatically blocks unwanted, leeching, and abnormal BitTorrent peers using customizable and cloud rules. From 5.0.0 until 9.3.15, the /api/statistic/analysis/field endpoint accepts a crafted field query parameter from an authenticated user and passes it to countField or sumField. The mapField() method forwards unrecognized field names without sanitization, so unrecognized field names are interpolated into SQL through ${field} across the SQLite, MySQL, and PostgreSQL mappers. Successful exploitation can read all data in the PeerBanHelper database. This issue is fixed in version 9.3.15. | ||||
| CVE-2026-111681 | 1 Smartloli | 1 Efak | 2026-10-19 | 8.8 High |
| EFAK through 5.1.0 contains a missing authorization vulnerability that allows authenticated low-privilege users to manage accounts because the /api/users endpoints lack administrator role checks. Attackers can send POST, PUT, or DELETE requests to UserController to grant themselves ROLE_ADMIN, create administrators, or delete users, gaining control of managed Kafka clusters. | ||||
| CVE-2026-111682 | 1 Smartloli | 1 Efak | 2026-10-19 | 6.5 Medium |
| EFAK 5.0.0 through 5.1.0 contains a missing authorization vulnerability that allows authenticated low-privilege users to read LLM provider API keys through the /api/model-config REST API. Attackers with any ROLE_USER account can query /api/model-config/page or /api/model-config/{id} to retrieve unmasked keys, enabling provider account access and incurred costs. | ||||
| CVE-2026-112141 | 1 Satya-vinay | 1 Events-management-system | 2026-10-19 | 7.3 High |
| A vulnerability was determined in satya-vinay Events-Management-System up to 437c77ceb69bf9fe2e3f4f46f7871b83f425383a. Affected is the function mysqli_query of the file doedit.php of the component Registration-Edit Handler. This manipulation of the argument id/name/title/year/gender/fromdate/todate/people causes sql injection. Remote exploitation of the attack is possible. The exploit has been publicly disclosed and may be utilized. This product follows a rolling release approach for continuous delivery, so version details for affected or updated releases are not provided. The project was informed of the problem early through an issue report but has not responded yet. | ||||
| CVE-2026-89072 | 1 Progress | 1 Moveit Transfer | 2026-10-19 | 7.5 High |
| Incorrect Authorization vulnerability in Progress MOVEit Transfer (Client Certificates module). This issue affects MOVEit Transfer: before 2025.1.6 and from 2026.0.0 before 2026.0.4. | ||||
| CVE-2026-109736 | 1 Mozilla | 1 Firefox | 2026-10-19 | 8.1 High |
| Frame poisoning in the Layout component. This vulnerability was fixed in Firefox 158, Firefox ESR 153.5, Thunderbird 158, and Thunderbird 153.5. | ||||
| CVE-2026-89076 | 1 Progress | 1 Moveit Transfer | 2026-10-19 | 7.2 High |
| Improper neutralization of special elements used in an SQL command ('SQL injection') vulnerability in Progress MOVEit Transfer (Custom Reports module). This issue affects MOVEit Transfer: before 2025.1.6 and from 2026.0.0 before 2026.0.4. | ||||
| CVE-2026-108124 | 1 Wordpress-extensions | 1 Wp Post Author | 2026-10-19 | 4.9 Medium |
| Improper neutralization of special elements used in an SQL command ('SQL injection') vulnerability in wp-post-author. This issue affects wp-post-author before 4.1.0. | ||||
| CVE-2026-108125 | 1 Wordpress-extensions | 1 Wp Post Author | 2026-10-19 | N/A |
| Improper neutralization of special elements used in an SQL command ('SQL injection') vulnerability in wp-post-author. This issue affects wp-post-author version 4.0.0 prior to 4.1.0. | ||||
| CVE-2026-6723 | 2 Croixhaug, Wordpress-extensions | 2 Simply Schedule Appointments, Simply Schedule Appointments | 2026-10-19 | 5.3 Medium |
| The Appointment Booking Calendar — Simply Schedule Appointments Booking Plugin plugin for WordPress is vulnerable to Incorrect Authorization in all versions up to, and including, 1.6.11.11. This is due to the appointment update REST API endpoint not restricting which fields can be modified by token-authenticated customers. This makes it possible for unauthenticated attackers to modify admin-controlled fields on that appointment, including faking payment confirmation, reassigning the appointment to another user, and changing the service type. | ||||
| CVE-2026-98641 | 1 Linux | 1 Linux Kernel | 2026-10-19 | 4.4 Medium |
| 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-18947 | 2 Red Hat, Redhat | 2 Red Hat Openshift Ai (rhoai), Openshift Ai | 2026-10-19 | 8.5 High |
| A flaw was found in Feast. An authorization bypass vulnerability exists in the /materialize and /materialize-incremental endpoints. By sending a specially crafted request that omits the feature_views field, an attacker can bypass intended permission checks. This allows an unauthenticated remote attacker, or any authenticated user, to trigger a full re-materialization of all feature views. The consequence is a Denial of Service (DoS) due to data corruption and significant resource consumption across all tenants. | ||||
| CVE-2026-98614 | 1 Linux | 1 Linux Kernel | 2026-10-19 | 7.5 High |
| In the Linux kernel, the following vulnerability has been resolved: sctp: avoid livelock while updating retransmit path sctp_assoc_update_retran_path() can loop forever when every remaining transport, including retran_path, is SCTP_UNCONFIRMED: the state check runs before the wraparound test, so the loop cannot observe that it has completed a full pass. Fix this by considering a transport only when it is not UNCONFIRMED, then checking whether the walk has returned to retran_path. This makes the full-pass termination independent of the transport state while preserving the existing fallback selection semantics. Also restore the NULL guard around the retran_path assignment. In the all-UNCONFIRMED case there is no eligible replacement transport, and installing NULL would leave later retransmit-path users and the debug print with a NULL path. | ||||
| CVE-2026-98610 | 1 Linux | 1 Linux Kernel | 2026-10-19 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: net/sched: sch_hfsc: bound the classify inner-filter walk with a drift budget hfsc_classify() applies the "filter may only point downwards" level check only when the filter result carries no bound class. A filter created with a flowid gets res.class set once at bind time, so the check never runs for it during classification. hfsc_adjust_levels() can later raise a class's level without revalidating existing bindings, leaving two binds that were each legal at bind time pointing at each other; the classify walk then bounces between two interior classes forever with the qdisc lock held and BH disabled — a soft lockup from a single packet. The stuck walk trips the watchdog: watchdog: BUG: soft lockup - CPU#3 stuck for 13s! [ping:444] RIP: 0010:u32_classify+0x542/0x17f0 ... tcf_classify+0x66/0xa0 hfsc_enqueue+0x166/0xdf0 Bound the traversal with a budget of non-descending hops, the only way a configured walk can move without descending the class tree once levels drift after bind time. The budget is cumulative over the whole walk and is deliberately not reset on a descending hop: a chain that alternates a descent with a lateral hop would return the budget every lap and never trip. Descending hops never decrement it, so legitimately deep trees are unaffected and a terminating lateral chain still classifies normally. Drop the packet with a rate-limited warning once the budget is exhausted, mirroring the merged HTB fix. This is a follow-up to commit 729c4896ab82 ("net/sched: sch_htb: limit htb_classify inner-class filter hops"), which bounded the same classify loop on the HTB side but left the HFSC walk unbounded. Conditions to recreate the bug: - CONFIG_NET_SCHED, CONFIG_NET_SCH_HFSC, CONFIG_NET_CLS_U32, CONFIG_LOCKUP_DETECTOR. - Build a cycle with two legal-at-bind-time flowid binds and a level drift: class X 1:1 (child of root) with leaf child 1:10; class Y 1:2 (sibling of X) with children 1:20 and 1:200; root u32 filter flowid 1:1; filter on X flowid 1:2 (legal when Y is a leaf); after Y's level rises to 2, filter on Y flowid 1:1 (legal then). Send one packet (ping on the device). Unfixed kernel: classify spins with the qdisc lock held; with softlockup_panic=1 it panics. - Reachable from unprivileged user via unshare -Urn (CAP_NET_ADMIN). | ||||
| CVE-2026-98571 | 1 Linux | 1 Linux Kernel | 2026-10-19 | 5.9 Medium |
| In the Linux kernel, the following vulnerability has been resolved: net: stmmac: clear stale buf->page after recycling on skb build failure In stmmac_rx(), when napi_build_skb() fails the descriptor page is recycled back to the page pool with page_pool_recycle_direct(), but buf->page is left pointing at the recycled page, unlike every other consumption site in the function which clears the pointer after handing the page away. With the stale pointer stmmac_rx_refill() skips the replacement allocation and programs the already-recycled page back into the RX descriptor. Clear buf->page on the napi_build_skb() failure path to keep the buffer lifecycle consistent with the other consumption sites. | ||||
| CVE-2026-98557 | 1 Linux | 1 Linux Kernel | 2026-10-19 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: gve: DQO: fix header length used by gve_can_send_tso() for UDP GSO gve_can_send_tso() computes how many buffers each segment of a GSO packet would span, and for this it needs the length of the headers that the device replicates in front of every segment. It unconditionally uses skb_tcp_all_headers(), which reads the doff field of the TCP header. SKB_GSO_UDP_L4 packets have no TCP header: tcp_hdrlen() then reads one byte of the UDP payload, and header_len can be anything in [0, 60] instead of the transport offset plus the eight bytes of the UDP header that gve_prep_tso() programs into the TSO context descriptor. A wrong header length shifts all the segment boundaries computed in the loop, so the number of buffers per segment can be over or under estimated. In the first case, GSO is needlessly disabled for this packet by gve_features_check_dqo() and the stack has to segment it. In the second case, the driver hands the device a packet whose segments span more than GVE_TX_MAX_DATA_DESCS buffers. Use the UDP header length for SKB_GSO_UDP_L4 packets, matching what gve_prep_tso() does. | ||||
| CVE-2026-98533 | 1 Linux | 1 Linux Kernel | 2026-10-19 | 4.1 Medium |
| In the Linux kernel, the following vulnerability has been resolved: ipe: protect the dm-verity root hash with RCU ipe_bdev_setintegrity() frees the old root hash when dm-verity publishes a new one on ->preresume, while policy evaluation can still be dereferencing it. Protect the root hash with RCU. The evaluation path already runs under rcu_read_lock(). [FW: remove model name according to latest guideline] | ||||
| CVE-2026-98521 | 1 Linux | 1 Linux Kernel | 2026-10-19 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: drm/i915: fix incorrect RCU teardown order i915_gem_busy_ioctl uses dma_resv_for_each_fence_unlocked() to iterate over the fences in an GEM object without holding a reference but only the RCU read side lock. What can happen here is that the GEM object is destroyed concurrently while i915_gem_busy_ioctl is still running. This won't free the GEM objects memory, but still drops all the dma_fence references. Now when dma_resv_for_each_fence_unlocked() sees a destroyed dma_fence it assumes that a new fence list was installed and re-starts the loop. But in the case of a destroyed GEM object a new fence list is never installed, only the old one freed and therefore the iteration never finishes resulting in an endless loop. The solution is to drop the fence references only after the RCU grace period. The fixes tag is not necessary the patch introducing the problem, but the one making it so worse that we need to address it. This problem was pointed out by Sashiko-bot. (cherry picked from commit 5113479556025093bf8133bb2dcaa33be2d50921) | ||||
| CVE-2026-98496 | 1 Linux | 1 Linux Kernel | 2026-10-19 | 4.1 Medium |
| In the Linux kernel, the following vulnerability has been resolved: net: airoha: npu: cancel wdt_work after releasing the WDT IRQ airoha_npu_remove() calls cancel_work_sync() on each core's wdt_work, but the watchdog IRQ that queues it is requested with devm_request_irq() and is freed only after .remove() returns. airoha_npu_wdt_handler() can therefore schedule_work() again once the cancel has returned. struct airoha_npu, which contains the work, is devm_kzalloc()'d and is freed in that same unwind, so the late work dereferences freed memory. Register the work with devm_work_autocancel() before devm_request_irq() and drop .remove(). Devres runs in reverse order, so the IRQ is freed before cancel_work_sync(), including when probe fails. A cancel left in .remove() cannot get that order. Initializing the work first also stops a pending watchdog interrupt from queuing an uninitialized work item. Probe currently calls INIT_WORK() only after devm_request_irq(). This issue was identified during our ongoing static-analysis research while reviewing kernel code. | ||||