CVE Watch364,217 in full archive

Vulnerabilities exploitable today

364,217in current view

Single score combining CVSS, KEV membership and EPSS. Every CVE with its own record — timeline from publication to active exploitation.

In KEV catalog1,674

New KEV · 24H0

Exploit Today ≥ 701,611

Distribution · last window

Critical
2,610
High
10,670
Medium
5,901
Low
563

Filters

Window

Severity

Flags

Vulnerabilities364,081–364,120 · 364,217

CVECVSSEPSSKEVRExploitTitleMod.

CVE-2026-76604—

—

———Joomla Extension - fabrikar.com - Unauthenticated remote code execution via PHP form element in Fabrik < 4.7.3 - The PHP form element is vulnerable to the execution of user provided codes.6h CVE-2026-76603—

—

———Joomla Extension - fabrikar.com - Unauthenticated row disclosure via form.inlineedit in Fabrik < 4.7.3 - The inineedit form controller does not perform any access checks, disclosing items to unauthorized users.6h CVE-2026-74642—

—

———In the Linux kernel, the following vulnerability has been resolved: ALSA: usb: Fix UAF at delayed release of MIDI2 EPs The recent fix for UAF in ump_to_endpoint() caused another UAF because it tries to dereference the UMP endpoint object, but this might be executed at a delayed context where the endpoint has been already released. Add private_free to clear the associated data for avoiding the further dereference for delayed releases.5h CVE-2026-74705—

—

———In the Linux kernel, the following vulnerability has been resolved: udp: fix potential use-after-free in tunnel segmentation __skb_udp_tunnel_segment() gets the UDP header before ensuring the tunnel header is in the skb head. If the pull reallocates skb->head, the saved UDP header pointer is no longer valid. Get the UDP header after the pull to avoid a potential use-after-free.5h CVE-2026-34245.3 MED

—

———The The kk Star Ratings – Rate Post & Collect User Feedbacks plugin for WordPress is vulnerable to arbitrary shortcode execution in all versions up to, and including, 5.4.10.3. This is due to the software allowing users to execute an action that does not properly validate the 'payload' value before running do_shortcode. This makes it possible for unauthenticated attackers to execute arbitrary shortcodes.9h CVE-2026-76602—

—

———Joomla Extension - fabrikar.com - Unauthenticated SQL injection in ORDER BY in Fabrik < 4.7.3 - The order parameter in list models is used in queries without validation, allowing read SQLi vectors.6h CVE-2026-42454.3 MED

—

———The Post Duplicator plugin for WordPress is vulnerable to authorization bypass in all versions up to, and including, 3.0.11. This is due to the `duplicate_post_permissions()` permission callback only verifying the `duplicate_posts` capability without checking whether the requesting user holds `publish_posts` or other status-gated capabilities. This makes it possible for authenticated attackers, with Contributor-level access and above, to create duplicate posts with `future` (scheduled, auto-publishes) or `private` status, bypassing editorial review. Additionally, the REST endpoint does not enforce administrator-configured post-type duplication restrictions, allowing duplication of post types that have been explicitly disabled.9h CVE-2026-74704—

—

———In the Linux kernel, the following vulnerability has been resolved: net/sched: sch_cake: drop WARN_ON(1) for malformed packets in ACK filter The sch_cake ACK filter parses packets to find the TCP header and filter duplicated ACKs if the flow is backlogged. The parsing code contains a WARN_ON(1) which can be triggered by a malformed IP header in certain cases. Depending on the system configuration, this leads either to either spamming dmesg with warnings, or a panic if panic_on_warn is set. The code already correctly skips the offending packet in the branch that triggers the warning, so the WARN_ON itself doesn't really serve any purpose. So just drop it altogether to avoid the inconvenient side effects.5h CVE-2026-76601—

—

———Joomla Extension - fabrikar.com - Unauthenticated row reordering in Fabrik < 4.7.2 - The order plugin did not perform any access checks.6h CVE-2026-76600—

—

———Joomla Extension - fabrikar.com - Unauthenticated deletion of any comment in Fabrik < 4.7.2 - The DeleteComment endpoint did not perform any access checks.6h CVE-2026-74703—

—

———In the Linux kernel, the following vulnerability has been resolved: vhost-scsi: Validate T10 PI scatterlist counts When T10 PI is negotiated, vhost-scsi splits protection bytes from the data iterator before mapping the request scatterlists. A malformed request can claim protection bytes that cover or exceed the full payload length. The former leaves no data bytes to map, while the latter underflows exp_data_len before advancing the iterator. Both cases can let a zero data SGL count reach sg_alloc_table_chained(), which triggers BUG_ON(!nents). Reject protection lengths that cover or exceed the payload before subtracting prot_bytes and advancing the iterator. Also propagate negative errors from the protection SGL calculation before calling the allocator, matching the data SGL path.5h CVE-2026-66916—

—

———Joomla Extension - joomgalleryfriends.net - Password-Protected Category Bypass via JSON Format in JoomGallery < 4.4.0- An unauthenticated access control bypass exists in JoomGallery's category JSON view. When a gallery category is protected with a password, the HTML view correctly enforces the password gate - but the JSON view ( format=json ) skips this check entirely.9h CVE-2026-74702—

—

———In the Linux kernel, the following vulnerability has been resolved: vhost-scsi: reject feature changes after endpoint vhost_scsi_setup_vq_cmds() runs from VHOST_SCSI_SET_ENDPOINT and allocates each command's protection scatterlist array (prot_sgl) according to the acknowledged VIRTIO_SCSI_F_T10_PI bit. The command pools are not rebuilt when VHOST_SET_FEATURES changes that bit later. Although virtio feature bits must not change after feature negotiation, vhost_scsi_set_features() currently accepts such a request after the endpoint is active and updates acked_features. Enabling T10-PI after endpoint setup therefore leaves prot_sgl NULL while the I/O path follows the new feature bit. For a 129-page protection payload, vhost_scsi_mapal() passes the missing first chunk to sg_alloc_table_chained(): sg_alloc_table_chained(table, 129, first_chunk=NULL, nents_first_chunk=inline_sg_cnt) sg_pool_index() then hits: BUG_ON(nents > SG_CHUNK_SIZE); /* 129 > 128 */ The kernel reported the following call trace and register state: Call Trace: <TASK> ? __sg_alloc_table+0x1d8/0x250 ? __pfx_vhost_run_work_list+0x10/0x10 [vhost] sg_alloc_table_chained+0x59/0xf0 ? __pfx_sg_pool_alloc+0x10/0x10 ? vhost_scsi_calc_sgls.constprop.0+0x43/0x60 [vhost_scsi] vhost_scsi_handle_vq+0xf02/0x1700 [vhost_scsi] ? __pfx_vhost_scsi_handle_vq+0x10/0x10 [vhost_scsi] vhost_scsi_handle_kick+0x37/0x50 [vhost_scsi] vhost_run_work_list+0x8e/0xd0 [vhost] vhost_task_fn+0xe1/0x210 ret_from_fork+0x348/0x540 </TASK> RIP: 0010:0x4 CR2 = 0x4 RSP: 0018:ffffc90000dbf940 EFLAGS: 00010202 RAX: ffffffff82396810 RBX: ffff88811dc28b80 RCX: 0000000000000000 RDX: 0000000000000000 RSI: 0000000000000820 RDI: 0000000000000081 VHOST_F_LOG_ALL is a vhost-specific runtime feature and remains the only exception. Reject changes to any feature other than VHOST_F_LOG_ALL while the endpoint is active. This preserves the existing runtime log toggle while preventing feature-dependent command resources and data-path state from becoming inconsistent. Userspace must clear the endpoint before changing any other negotiated feature and set the endpoint up again afterward.5h CVE-2026-76599—

—

———Joomla Extension - fabrikar.com - Unauthenticated database table list and table-prefix disclosure in Fabrik < 4.7.2 - The ajax_tables method of the elements model allows listings of arbitrary database tables including columns.6h CVE-2026-74701—

—

———In the Linux kernel, the following vulnerability has been resolved: net/openvswitch: check Ethernet header length in key_extract() When a packet arrives on an ARPHRD_NONE device (e.g. TUN), ovs_flow_key_extract() trusts the user-provided skb->protocol field: if it is ETH_P_TEB, the packet is classified as MAC_PROTO_ETHERNET and key_extract() is called without ensuring the skb has ETH_HLEN (14) bytes of linear data. key_extract() unconditionally pulls 2 * ETH_ALEN bytes for MAC addresses and parse_ethertype() pulls 2 more, either of which triggers a kernel BUG in __skb_pull() when the linear area is too small. kernel BUG at include/linux/skbuff.h:2848! RIP: 0010:key_extract+0xa7e/0xd90 net/openvswitch/flow.c:933 ovs_flow_key_extract+0x419/0xa70 ovs_vport_receive+0x222/0x390 netdev_frame_hook+0x3e0/0x630 tun_get_user+0x2d0c/0x38e0 Fixed by calling check_header() in key_extract() before accessing the Ethernet header.5h CVE-2026-600834.9 MED

—

———SiYuan versions before v3.8.0 contain an incomplete path blocklist in the MCP file tool that fails to restrict access to sensitive workspace files protected by the HTTP API. Authenticated administrators can read plaintext publish-mode passwords from data/.siyuan/publishAccess.json and access other sensitive files like data/templates and data/snippets/conf.json.8h CVE-2026-74700—

—

———In the Linux kernel, the following vulnerability has been resolved: net/sched: cls_api: Always acquire rtnl_lock when destroying locked classifiers Another challenge with unlocked filters. There is a short window in tc_new_tfilter where a tcf_proto can be found and briefly referenced by a totally unrelated, unlocked classifier's request and cause a race. Feng created a poc which created this race with two threads, one creating a u32 filter and other a flower filter in the same chain/prio: 1. Both threads enter tc_new_tfilter, both find the chain empty, both drop filter_chain_lock 2. u32 finishes tcf_proto_create("u32") first, calls tcf_chain_tp_insert_unique() -> inserts u32_tp into the chain 3. flower finishes tcf_proto_create("flower") later, calls tcf_chain_tp_insert_unique() -> tcf_chain_tp_find() now sees u32_tp already there, takes a reference on it, destroys flower's own tp_new and returns u32_tp to the caller. Flower then hits the kind mismatch check (because it requested for kind "flower" but tp->ops->kind is "u32") and goes through the errout path which calls tcf_proto_put() on u32_tp. If the u32 thread has already gone through its own errout (its change() call failed on the PoC's empty options) and dropped its create and insert refs, flower's put is the last one and drops u32_tp's refcnt to zero. At this point tp->ops->destroy() runs in a context that never took rtnl_lock. When that happens, it might cause a UAF like the following (illustrated by the PoC): [ +0.000710] BUG: KASAN: slab-use-after-free in u32_init (net/sched/cls_u32.c:393) [ +0.000281] Read of size 8 at addr ffff888120022f00 by task poc_feng_xue/524 Call Trace: u32_init (net/sched/cls_u32.c:393) tc_new_tfilter (net/sched/cls_api.c:2378) Allocated by task 526: u32_init (net/sched/cls_u32.c:378) tc_new_tfilter (net/sched/cls_api.c:2378) Freed by task 522: kfree u32_destroy (net/sched/cls_u32.c:662) tcf_proto_destroy (net/sched/cls_api.c:446) tcf_proto_put (net/sched/cls_api.c:459) tc_new_tfilter (net/sched/cls_api.c:2459) Fix this by having tcf_proto_destroy() take rtnl_lock around tp->ops->destroy() for locked classifiers whenever rtnl is not held. To explain why I used a temp variable "not_lockless" I'd like to point to a semi-related note on rtnl_held vs TCF_PROTO_OPS_DOIT_UNLOCKED (adding here for future cleanup if deemed necessary): The rtnl_held parameter and the TCF_PROTO_OPS_DOIT_UNLOCKED flag are redundant sources of truth for whether rtnl_lock is held. Among the nine classifier destroy(..rtnl_held..) callbacks, only flower consults the rtnl_held parameter which it propagates to tc_setup_cb_destroy() and tc_setup_cb_call(). The other eight (u32, flow, bpf, cgroup, route, basic, fw, mall) ignore it entirely;-> those that call tc_setup_cb_destroy() (u32, bpf, mall) hardcode true always instead of forwarding the parameter. A future cleanup should remove the rtnl_held parameter from the destroy callback signature entirely and have callers rely solely on their knowledge whether they are running in an unlocked context.5h CVE-2026-76598—

—

———Joomla Extension - fabrikar.com - Unauthenticated arbitrary directory listing via onAjax_getFolders in Fabrik < 4.7.2 - The onAjax_getFolders method of the elements model allows arbitrary directory listings.6h CVE-2026-74658—

—

———In the Linux kernel, the following vulnerability has been resolved: futex: Prevent robust futex exit race some more A robust futex unlock stores 0 over the whole futex value - wiping FUTEX_WAITERS - and wakes a single waiter. That wakeup is a one-shot notification: the protocol relies on its recipient to either acquire the futex (and eventually unlock while aware of the remaining contention) or re-arm FUTEX_WAITERS before sleeping again. If the woken waiter is killed before it can do either, the kernel must jump in and wake the next task down the line. This is a known complication of the futex protocol with a previous partial fix in commit ca16d5bee598 ("futex: Prevent robust futex exit race"). Unfortunately, that fix is insufficient. If a third task re-acquired the futex through the uncontended fast path in the meantime, the notification is lost: robust exit processing sees that it is owned by another task and does nothing, while the new owner sees no FUTEX_WAITERS when it unlocks and wakes nobody. The remaining waiters sleep forever behind a free futex: A owns the futex, B and C sleep in FUTEX_WAIT uval == A | FUTEX_WAITERS A robust unlock: store 0, FUTEX_WAKE(1) wakes B uval == 0 D fast path acquire: cmpxchg(0 -> D) uval == D, no FUTEX_WAITERS B killed before acting on the wakeup B exit walk, pending op: owner D != B -> no action D unlock: no FUTEX_WAITERS -> no wake C sleeps forever This is clearly a shortcoming in the implementation, which fails to keep the FUTEX_WAITERS bit consistent. Work around this by augmenting the robust list exit processing to also perform the extra wakeup if the futex word is owned by another thread but FUTEX_WAITERS is not set. This does not fix the problem of a non-contended take over/release and free sequence, which has been discussed for years and has been addressed by commit 3ca9595d9fb6 ("futex: Add support for unlocking robust futexes") and subsequent changes, but failed to take the problem described above into account. A more complete solution which is based on the in kernel unlock of contended robust futexes has been discussed in the context of this change and should show up in mainline sooner than later. [ tglx: Amend change log slightly and fixup coding style ]5h CVE-2026-74667—

—

———In the Linux kernel, the following vulnerability has been resolved: net/packet: reset the MAC header on the packet-socket transmit path packet_parse_headers() resets the MAC header only for a SOCK_RAW frame whose socket did not bind a protocol. A protocol-bound SOCK_RAW socket, any SOCK_DGRAM frame, and the legacy SOCK_PACKET path therefore leave skb->mac_header unset here. For frames sent via __dev_queue_xmit() this is harmless: it resets the MAC header unconditionally. But the packet-socket PACKET_QDISC_BYPASS path uses dev_direct_xmit(), which does not, so the frame reaches ndo_start_xmit() with the MAC header unset. A driver that reads eth_hdr(skb) on transmit then dereferences skb->head + (u16)~0, an out-of-bounds access ~64 KiB past the head -- the same class fixed for one consumer in commit f5089008f90c ("macsec: do not read an unset MAC header in macsec_encrypt()"). packet_parse_headers() runs only on the transmit path, where skb->data points at the start of the L2 header for every packet-socket type regardless of its length: SOCK_RAW and SOCK_PACKET carry a user-supplied header and SOCK_DGRAM has one built by dev_hard_header(). Reset the MAC header unconditionally, mirroring __dev_queue_xmit(), so the frame is anchored on the bypass path too. Found by 0sec (https://0sec.ai) using automated source analysis; verified against source and matched to the macsec KASAN report in f5089008f90c. Compile-tested.5h CVE-2026-66917—

—

———Joomla Extension - joomgalleryfriends.net - Stored XSS in JoomGallery < 4.4.0 - An authenticated, privileged can store an XSS payload in any image causing JS execution in every visitor's browser.9h CVE-2026-76597—

—

———Joomla Extension - fabrikar.com - Unauthenticated arbitrary file upload to web root via list email plugin in Fabrik < 4.7.2 - The list email plugin controller allows to upload non-executable files to the webroot.6h CVE-2026-74643—

—

———In the Linux kernel, the following vulnerability has been resolved: samples/damon/mtier: error out for zero quota goal target values Patch series "mm/damon: avoid division by zero from damos_quota_score()". DAMON_SAMPLE_MTIER and DAMON_LRU_SORT allow the user to trigger division by zero in damos_quota_score(). Avoid it by adding parameters validation checks. This patch (of 2): damos_quota_score() can trigger division by zero if the target_value is zero. DAMON_SAMPLE_MTIER lets users set the target_value via node0_mem_{used,free}_bp parameters. It doesn't guard zero value case, though. As a result, users can trigger division by zero. Fix the issue by returning an error when the user tries to start DAMON with zero node0_mem_{used,free}_bp parameter values. DAMON_SAMPLE_MTIER is just a sample module, but the consequence is quite bad. Also the zero node0_mem_free_bp parameter might look like a reasonable setup to some users. Hence, the issue might really happen in the real world. One reliable way to reproduce the issue is like below: # cd /sys/module/damon_sample_mtier/parameters # echo 4096 > node0_start_addr # echo 8192 > node0_end_addr # echo 8192 > node1_start_addr # echo 81920 > node1_end_addr # echo 0 > node0_mem_free_bp # echo Y > enabled # dmesg -w [...] [18792.235916] Oops: divide error: 0000 [#1] SMP NOPTI [...] [18792.242787] RIP: 0010:damos_quota_score+0x6f/0x480 [...] This issue was discovered [1] by Sashiko.5h CVE-2026-74666—

—

———In the Linux kernel, the following vulnerability has been resolved: packet: synchronize pressure clearing with ring reconfiguration packet_set_ring() updates the RX ring state under sk_receive_queue.lock, but used to publish the tpacket receive mode through po->prot_hook.func after releasing that lock. packet_poll() and packet_recvmsg() can then run the pressure clearing path after the ring has been cleared while still seeing tpacket_rcv, causing __packet_rcv_has_room() to dereference stale or NULL ring storage. Move the existing receive hook assignment into the same sk_receive_queue.lock section as the ring state update. Keep the assignment otherwise unchanged, including on TX ring reconfiguration, to avoid adding behavior changes that are not required for the fix. Serialize packet_recvmsg() pressure clearing with the same queue lock only after PACKET_SOCK_PRESSURE has been observed. If the flag is clear and the socket has moved away from tpacket_rcv, packet_set_ring() has already detached the socket and waited for synchronize_net(), so no new packet input can set the flag again. packet_poll() already holds sk_receive_queue.lock, so it uses the new unlocked helper directly.5h CVE-2026-76596—

—

———Joomla Extension - fabrikar.com - Unauthenticated table truncation via list.doempty in Fabrik < 4.7.2- The list controllers doemtpy endpoints lacks ACL gates, a plain GET empties the target list's table6h CVE-2026-74699—

—

———In the Linux kernel, the following vulnerability has been resolved: drm/xe: Fix memory leak in exec_queue_set_hang_replay_state() The q->replay_state is blindly overwritten, which can potentially leak memory that was previously allocated by vmemdup_user(). Return an error if q->replay_state is not empty. Discovered using AI-assisted static analysis confirmed by Intel Product Security. (cherry picked from commit f6b6cc1118bdbc4265fa8b3bdf8565b26f13e56e)5h CVE-2026-74698—

—

———In the Linux kernel, the following vulnerability has been resolved: net/mlx5e: fix BQL reset on SQ re-activation mlx5e_queue_start() deactivates and re-activates all channels but closes only the queue being restarted. mlx5e_activate_txqsq() then unconditionally calls netdev_tx_reset_queue(), zeroing the BQL counters of channels that kept their in-flight TX WQEs. The next completion then over-charges and trips the BUG_ON() in dql_completed(): kernel BUG at lib/dynamic_queue_limits.c:99! RIP: 0010:dql_completed+0x23d/0x280 Call Trace: <IRQ> mlx5e_poll_tx_cq+0x668/0xa60 mlx5e_napi_poll+0x5b/0x7b0 net_rx_action+0x15a/0x580 Reset BQL only when the SQ has no bytes in flight (sq->cc == sq->pc). In the case that reset is skipped, the outstanding WQEs will eventually complete and rebalance the dql. The dql->limit is carried across the reset.5h CVE-2026-74697—

—

———In the Linux kernel, the following vulnerability has been resolved: bnxt_en: Disable EOP for TPA on all chips to prevent data corruption EOP (End of frame padding) on the AGG ring may cause overlapping of zero padding at the end of one segment with the next segment's data. If Relaxed Ordering (RO) is enabled, the zero padding may overwrite valid data in the next segment and corrupt the data. Older chips (P5 and older) do not automatically disable RO when EOP is enabled. On some ARM systems, data corruption was reported on 57508 (P5) chips with RO enabled. Always disable EOP on all chips on the AGG rings when TPA is enabled to fix the data corruption.5h CVE-2026-74696—

—

———In the Linux kernel, the following vulnerability has been resolved: tcp: fix TFO max_qlen accounting across reuseport migration A listener's TCP_FASTOPEN max_qlen stops being accurate and lets through far more pending Fast Open requests than it was configured for. This only shows up with SO_REUSEPORT listener migration, where closing a listener hands its still-pending TFO children over to a surviving one. fastopenq.qlen is charged in tcp_fastopen_create_child() when the child is created and uncharged in reqsk_fastopen_remove() when the handshake completes. The uncharge follows rsk_listener of the request the child points at, and inet_reqsk_clone() has repointed the child at a new request owned by the new listener, so the ++ and the -- land on two different sockets. The new listener's qlen drifts negative and its limit no longer binds. Charge the new listener during migration, like reqsk_queue_migrated() already does for queue->young and queue->qlen.5h CVE-2026-74644—

—

———In the Linux kernel, the following vulnerability has been resolved: mm/damon/ops-common: putback folios on invalid migrate nid damon_pa_migrate() and damos_va_migrate() isolate folios into a local list and then call damon_migrate_pages(). When target_nid is invalid (including the scheme default NUMA_NO_NODE / -1), damon_migrate_pages() returns early without putting the folios back to the LRU. Callers then discard the list head while those folios remain isolated with an extra reference taken by folio_isolate_lru(). The pages stay off the LRU for as long as the mapping exists (anon active+inactive counts drop while RSS does not), and the leftover references can pin the pages after the mapping is gone. Put the folios back on the invalid-nid path so ignored migration requests still return them to the LRU.5h CVE-2026-74645—

—

———In the Linux kernel, the following vulnerability has been resolved: mm/damon/lru_sort: error out for >10000 active_mem_bp damos_quota_score() can trigger division by zero if the target value is zero. DAMON_LRU_SORT lets users set the target value for the hot memory scheme via active_mem_bp parameter. It avoids setting it as the target value if the parameter value is zero. However, it also sets the cold memory scheme with a target value that is calculated as '10000 - active_mem_bp + 2'. Hence, if a user sets active_mem_bp 10002, the cold memory scheme's quota goal target value can be zero. As a result, division by zero can be triggered. Fix by returning an error when the user tries to start DAMON with >10000 active_mem_bp parameter value. It makes no sense to set active_mem_bp with 10002. It also requires module parameters write permission to reproduce the issue. That said, the consequence is quite bad. One reliable way to reproduce the issue is like below: # cd /sys/module/damon_lru_sort/parameters # echo 1000 > wmarks_high # echo 995 > wmarks_mid # echo 0 > wmarks_low # echo 10002 > active_mem_bp # echo Y > enabled # dmesg -w [...] [ 597.421247] Oops: divide error: 0000 [#1] SMP NOPTI [ 597.428848] RIP: 0010:damos_quota_score+0x6f/0x480 This issue was discovered [1] by Sashiko.5h CVE-2026-74695—

—

———In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_flow_table: drop existing skb dst before skb_dst_set_noref() Incoming skbs passing through netfilter flowtable offload hooks (or XFRM offload path) might already carry a ref-counted dst_entry assigned during earlier RX or routing steps. Calling skb_dst_set_noref() when skb already holds a ref-counted dst overwrites skb->_skb_refdst, leaking the previous dst_entry reference count and triggering a DEBUG_NET_WARN_ON_ONCE assertion in skb_dst_check_unset(): WARNING: at skb_dst_check_unset include/linux/skbuff.h:1170 WARNING: at skb_dst_set_noref include/linux/skbuff.h:1234 WARNING: at nf_flow_offload_ip_hook+0xf6c/0x2b60 net/netfilter/nf_flow_table_ip.c:864 Drop any existing dst_entry reference with skb_dst_drop(skb) before setting the non-referenced flowtable destination.5h CVE-2026-779886.6 MED

—

———A weakness has been identified in TRENDnet TEW-823DRU 1.1.02b01. This vulnerability affects the function nvram_get of the component CLI Configuration Tool. This manipulation causes command injection. The attack is possible to be carried out remotely. The exploit has been made available to the public and could be used for attacks.9h CVE-2026-74694—

—

———In the Linux kernel, the following vulnerability has been resolved: net/ncsi: fix heap OOB read in NCSI_CMD_SEND_CMD payload length ncsi_send_cmd_nl() takes the number of bytes to copy from the attacker-controlled ncsi_pkt_hdr.length field of the in-band packet header, while the source buffer is the NCSI_ATTR_DATA netlink attribute whose readable size is nla_len() - sizeof(ncsi_pkt_hdr). The two length sources are never cross-checked: only nla_len() >= sizeof(struct ncsi_pkt_hdr) is enforced. With hdr->length set larger than the attribute payload (up to 65535 against at most 2032 readable bytes), ncsi_cmd_handler_oem() copies past the end of the netlink attribute buffer with unsafe_memcpy(), leaking up to ~64KB of kernel heap memory into the transmitted NCSI command packet. The destination skb is sized by the declared payload, so the write side does not overflow - this is a pure OOB read / information leak, reachable with CAP_NET_ADMIN on systems with a registered NCSI device (e.g. OpenBMC on Aspeed BMC SoCs, where NET_NCSI=y is standard). Reject commands whose declared payload extends past the end of the data attribute. The issue was found by the autokbug dynamic kernel fuzzer at Tencent Yunding Lab.5h CVE-2026-11947—

—

———Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.8h CVE-2026-76571—

—

———Joomla Extension - fabrikar.com - Unauthenticated SQL injection in list filter condition parameter in Fabrik < 4.7.3 - The condition parameter passed to a list filter is concatenated verbatim into the WHERE clause built by getFilterQuery(). An unauthenticated attacker can supply arbitrary SQL through the filter condition, giving full read of the database.6h CVE-2026-74584—

—

———In the Linux kernel, the following vulnerability has been resolved: RDMA/bnxt_re: zero shared page before exposing to userspace bnxt_re_alloc_ucontext() allocates uctx->shpg via __get_free_page(GFP_KERNEL). The buddy allocator does not zero pages without __GFP_ZERO, so the page contains stale kernel data from whatever object most recently freed it. The page is then mapped into userspace via vm_insert_page() under BNXT_RE_MMAP_SH_PAGE in bnxt_re_mmap(). The driver only ever writes 4 bytes (a u32 AVID) at offset BNXT_RE_AVID_OFFT (0x10) inside bnxt_re_create_ah(); the remaining 4092 bytes of the page are exposed to userspace unsanitised, leaking kernel memory contents. Any user with access to /dev/infiniband/uverbsX on a host with a bnxt_re device (typically rdma group membership) can read this data via a single mmap() at pgoff 0 after IB_USER_VERBS_CMD_GET_CONTEXT. Other shared pages in the same file already use get_zeroed_page() correctly: drivers/infiniband/hw/bnxt_re/ib_verbs.c srq->uctx_srq_page = (void *)get_zeroed_page(GFP_KERNEL); cq->uctx_cq_page = (void *)get_zeroed_page(GFP_KERNEL); uctx->shpg is the only outlier. Bring it in line with the existing convention by switching to get_zeroed_page().6h CVE-2026-11948—

—

———Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.8h CVE-2026-706266.2 MED

—

———NLTK versions before 3.9.4 contain a symlink escape vulnerability in CorpusReader.open() that allows local attackers to read arbitrary files outside the corpus root. The vulnerability exists because path validation is lexical and does not account for symlink resolution, enabling attackers to place symlinks inside the corpus root to access files outside the intended boundary.6h CVE-2026-623816.6 MED

—

———luci-lib-px5g (LuCI) contains a heap-based buffer overflow in the native ASN.1 encoding routine asn1_add_obj (x509write.c) when signing a certificate with a 2040-bit RSA key. For a 255-byte signature, the BIT STRING allocation is computed from the DER length encoding of 255 bytes, but the payload written after prepending the unused-bits byte is 256 bytes, requiring one additional DER length octet. As a result the allocation is 259 bytes while the tag, length, unused-bits byte, and signature require 260 bytes, and the final memcpy writes one byte beyond the heap buffer. The overflow is reachable through the exported Lua interface via create_selfsigned(); whether it is remotely exploitable depends on the embedding application. The vulnerable code is present on the openwrt-18.06 through openwrt-25.12 release branches and is absent from master, where the luci-lib-px5g package has been removed rather than patched.8h