| CVE-2026-81654 | The Photo Gallery, Sliders, Proofing and WordPress plugin before 4.5.0 does not check that a user holds its options capability before saving image sizing settings, allowing users granted only its gallery-management capability by an administrator to change settings that apply across the whole site. | low | 2026-09-21 |
| CVE-2026-81653 | The Photo Gallery, Sliders, Proofing and WordPress plugin before 4.5.0 does not verify that the user acting on an image owns the gallery it belongs to, allowing users granted its gallery-management capability by an administrator to delete, copy and re-tag any image on the site, including images in galleries belonging to other users. | medium | 2026-09-21 |
| CVE-2026-81652 | The Photo Gallery, Sliders, Proofing and WordPress plugin before 4.5.0 does not verify that the requesting user is entitled to a given image record before returning it, allowing users with the Contributor role and above to read the stored metadata of any image on the site, including images in galleries belonging to other users. The disclosed data includes the image's stored EXIF subset, covering camera make and model and capture timestamp, along with internal checksums and identifiers that the Photo Gallery, Sliders, Proofing and WordPress plugin before 4.5.0's own capability-gated read path reserves to administrators. | low | 2026-09-21 |
| CVE-2026-81651 | The Photo Gallery, Sliders, Proofing and WordPress plugin before 4.5.0 does not verify that the user saving a gallery owns it, allowing any user granted its gallery-management capability by an administrator to overwrite the stored settings of any gallery on the site, including its filesystem path, and including galleries belonging to other users. | low | 2026-09-21 |
| CVE-2026-81650 | The Photo Gallery, Sliders, Proofing and WordPress plugin before 4.5.0 does not correctly validate the extensions of files extracted from an uploaded archive, due to a variable being reused as a loop counter so that the check always passes, allowing users granted its gallery-management capability by an administrator to write arbitrary files into a web-accessible directory and, on hosts that execute them, run arbitrary code. | high | 2026-09-21 |
| CVE-2026-81627 | A flaw was found in QEMU. The VAPIC setup hypercall in hw/i386/vapic.c does not validate that the writable RAM alias remains within the option ROM window. A privileged guest user on a Q35/KVM machine can position this alias over locked SMRAM, bypassing chipset D_LCK protection and injecting code into System Management Mode memory. | medium | 2026-09-21 |
| CVE-2026-81531 | An information disclosure vulnerability has been identified in Omada Controller. An API endpoint intended for Controller initialization remains accessible after completion and may disclose account-related information to unauthenticated remote users. Successful exploitation may allow an attacker to remote query the affected endpoint that may facilitate user enumeration and subsequent attacks targeting administrative accounts. | medium | 2026-09-21 |
| CVE-2026-81515 | Steeltoe is an open source project that provides a collection of libraries that helps users build cloud-native applications. From 4.0.0 until 4.3.0, EurekaDiscoveryClient deserializes the registry response as one unit, and an unrecognized actionType or status, a non-Boolean isCoordinatingDiscoveryServer, or a nonnumeric timestamp can abort the entire response. A principal that can register or update an instance can cause all connected Steeltoe clients to receive an empty or stale instance list until the malformed registration is removed. The JsonInstanceInfoConverter, BoolStringJsonConverter, and LongStringJsonConverter parsing paths are affected. This issue is distinct from the earlier DataCenterInfo.name parsing vulnerability. This issue is fixed in version 4.3.0. | high | 2026-09-21 |
| CVE-2026-81469 | Dell Inventory Collector Client, versions prior to 15.0.0, contain an Unquoted Search Path or Element vulnerability. A low privileged attacker with local access could potentially exploit this vulnerability, leading to Code execution and Elevation of Privileges | high | 2026-09-21 |
| CVE-2026-81240 | Dell Wyse Management Suite, versions prior to 2605.0.3.683, contain an Unrestricted Upload of File with Dangerous Type vulnerability. An unauthenticated attacker with remote access could potentially exploit this vulnerability, leading to Remote execution. | critical | 2026-09-21 |
| CVE-2026-81238 | Dell Wyse Management Suite, versions prior to 2605.0.3.683, contain a Missing Authentication for Critical Function vulnerability. An unauthenticated attacker with remote access could potentially exploit this vulnerability, leading to Unauthorized access. | critical | 2026-09-21 |
| CVE-2026-81237 | Dell Wyse Management Suite, versions prior to 2605.0.3.683, contain an Improper Authentication vulnerability. An unauthenticated attacker with remote access could potentially exploit this vulnerability, leading to Unauthorized access. | medium | 2026-09-21 |
| CVE-2026-81236 | Dell Wyse Management Suite, versions prior to 2605.0.3.683, contain an Unrestricted Upload of File with Dangerous Type vulnerability. An unauthenticated attacker with remote access could potentially exploit this vulnerability, leading to Remote execution. | critical | 2026-09-21 |
| CVE-2026-81235 | Dell Wyse Management Suite, versions prior to 2605.0.3.683, contain a Missing Cryptographic Step vulnerability. A high privileged attacker with remote access could potentially exploit this vulnerability, leading to Information tampering. | medium | 2026-09-21 |
| CVE-2026-81181 | SysReptor is a fully customizable pentest reporting platform. Prior to 2026.68, the password authentication flow for protected shared notes does not rotate the session identifier after successful authentication, allowing session fixation. An attacker who can obtain an unauthenticated SysReptor session cookie, place it in a victim's browser, and know the shared-note URL where the victim authenticates can reuse the fixed session after the victim enters the correct password and access that shared note. The main SysReptor login flow is not affected. This issue is fixed in version 2026.68. | low | 2026-09-21 |
| CVE-2026-80945 | In the Linux kernel, the following vulnerability has been resolved: crypto: iaa - unmap dst before software fallback on decompress On a hardware analytics error, decompress retries through the software fallback, which writes req->dst with the CPU while it is still mapped DMA_FROM_DEVICE. With SWIOTLB active the later dma_unmap_sg() copies the stale bounce buffer over req->dst, corrupting the result. Unmap before the fallback runs. The async path unmaps inline; the sync path signals the retry with -EAGAIN so iaa_comp_adecompress() runs the fallback after unmapping. | critical | 2026-09-21 |
| CVE-2026-80926 | In the Linux kernel, the following vulnerability has been resolved: ksmbd: fix use-after-free in oplock break notification smb2_oplock_break_noti() reads opinfo->conn without any lock and dereferences it after two allocations which may sleep. When the durable handle owning the oplock is disconnected, session_fd_check() clears opinfo->conn and drops its conn reference under ci->m_lock, and the last ksmbd_conn_put() frees the connection. A break triggered by another connection that races with the teardown can then resurrect the freed connection: ksmbd_conn_get() is a plain atomic_inc, and the queued break work later dereferences the stale conn via ksmbd_conn_write(), a use-after-free reachable by any authenticated client holding a durable batch oplock. Thread the caller's inode into the notification path instead of taking a new reference on it. Every caller of oplock_break() already holds a live ksmbd_file (or an explicit ksmbd_inode_lookup_lock() reference, in the parent lease break paths) on the inode that owns the break target's oplock list, so ci cannot be freed during the call, and its lock can be taken without dereferencing opinfo->o_fp, which a concurrent close may free. Select and pin the connection under ci->m_lock, the same lock session_fd_check() and ksmbd_reopen_durable_fd() use to update opinfo->conn, so a concurrent detach either loses the race to the clear or keeps the connection alive until the notification work releases it. Transfer the reference to the work item and release it on allocation failures. | critical | 2026-09-21 |
| CVE-2026-80925 | In the Linux kernel, the following vulnerability has been resolved: vlan: fix skb_under_panic and races when toggling HW VLAN offload Toggling hardware VLAN TX offload (NETIF_F_HW_VLAN_CTAG_TX or NETIF_F_HW_VLAN_STAG_TX) on a lower device invokes vlan_transfer_features(), which dynamically changed vlandev->hard_header_len. This causes two issues: 1. Lockless TX paths (e.g. packet_snd in af_packet.c, ip6_finish_output2) read dev->hard_header_len without holding RTNL lock. Mutating hard_header_len dynamically under RTNL creates a data race where upper layers reserve insufficient headroom based on a stale hard_header_len, resulting in skb_under_panic when vlan_dev_hard_header() is called. 2. In addition, vlan_transfer_features() updated hard_header_len without updating header_ops, causing a mismatch between allocated headroom and header creation. Always setting dev->hard_header_len = real_dev->hard_header_len and dev->needed_headroom = real_dev->needed_headroom + VLAN_HLEN unconditionally ensures: - dev->hard_header_len remains 100% static and immutable at real_dev->hard_header_len, eliminating all dynamic runtime updates and data races on hard_header_len. - Upper layers allocating skbs via LL_RESERVED_SPACE() will always reserve sufficient headroom for software VLAN tag insertion (real_dev->hard_header_len + real_dev->needed_headroom + VLAN_HLEN). - vlandev inherits real_dev->needed_tailroom so underlying trailer/padding/ICV requirements are honored. - AF_PACKET SOCK_RAW network header offsets remain correctly aligned at real_dev->hard_header_len. - vlan_header_ops is used unconditionally. Note to stable teams: Make sure to backport these commits: e16e960d55a4 ("ipvlan: inherit needed_headroom and needed_tailroom from phy_dev") cef51860becd ("macvlan: inherit needed_headroom and needed_tailroom from lowerdev") | medium | 2026-09-21 |
| CVE-2026-80861 | In the Linux kernel, the following vulnerability has been resolved: usb: xhci: bail out of setup if the controller is inaccessible xhci_gen_setup() locates the operational registers using the capability length read from the very first register: xhci->op_regs = hcd->regs + HC_LENGTH(readl(&xhci->cap_regs->hc_capbase)); If the controller is dead or has dropped off the bus, that read returns ~0, HC_LENGTH() truncates it to 0xff, and op_regs ends up 0xff bytes past the page-aligned MMIO base, i.e. unaligned. The first access through it, xhci_halt() -> xhci_handshake() reading op_regs->status, is then an unaligned readl() on device memory. arm64 faults on unaligned device accesses, so instead of xhci_handshake() catching the all-ones value and returning -ENODEV, setup oopses: xhci-pci-renesas 0005:08:00.0: Unable to change power state from D3cold to D0, device inaccessible xhci-pci-renesas 0005:08:00.0: xHCI Host Controller xhci-pci-renesas 0005:08:00.0: new USB bus registered, assigned bus number 1 Unable to handle kernel paging request at virtual address ffff80030a770103 ESR = 0x0000000096000021 FSC = 0x21: alignment fault Internal error: Oops: 0000000096000021 [#1] SMP pc : xhci_halt [xhci_hcd] Call trace: xhci_halt xhci_gen_setup xhci_pci_setup usb_add_hcd usb_hcd_pci_probe xhci_pci_common_probe xhci_pci_renesas_probe This was hit with a Renesas uPD720201 that failed to power up ("Unable to change power state from D3cold to D0, device inaccessible") yet still reached the HCD probe path. Read the capability register once, and if it reads back the all-ones value (as xhci_handshake() and xhci_reset() already test for), abort setup with -ENODEV before op_regs is derived from it. Reading it once also avoids re-reading a register that may change under a concurrent hot-removal. | medium | 2026-09-21 |
| CVE-2026-80860 | In the Linux kernel, the following vulnerability has been resolved: fuse: fix race between interrupt and resend After commit f8fce75fedf7 ("fuse: clear intr_entry in fuse_resend and fuse_remove_pending_req") the WARN_ON(!list_empty(&req->intr_entry)) in fuse_request_free() still triggers due to the following race: In request_wait_answer() if (test_bit(FR_SENT, &req->flags)) -> returns true In fuse_chan_resend() clear_bit(FR_SENT, &req->flags) In request_wait_answer() queue_interrupt(req) Fix by: - move clearing FR_SENT inside fpq->lock - move setting FR_PENDING inside fiq->lock - recheck FR_SENT after acquiring fiq->lock in fuse_dev_queue_interrupt() | medium | 2026-09-21 |
| CVE-2026-80847 | In the Linux kernel, the following vulnerability has been resolved: tcp: clamp route advmss to TCP_MIN_MSS tcp_select_initial_window() assumes that callers never pass an MSS smaller than 1, but route-derived advmss values can violate that assumption. A too-small explicit RTAX_ADVMSS is one way to get there, but it is not the only one. The same divide-by-zero can also be reached through the "default advmss" path when RTAX_ADVMSS is left at 0 and the effective advmss is later driven down by route MTU and min_adv_mss. Introduce a tcp_dst_advmss() helper that clamps route advmss to TCP_MIN_MSS before TCP consumes it, and use it in the TCP paths that derive advmss from dst metrics. This keeps the effective MSS from dropping to zero before tcp_select_initial_window() rounds the receive window. | medium | 2026-09-21 |
| CVE-2026-80841 | In the Linux kernel, the following vulnerability has been resolved: net/packet: defer vmalloc TX_RING free until skbs finish AF_PACKET TX_RING skbs keep a raw pointer to their ring frame. The skb page references preserve page-backed ring blocks after pg_vec is freed, but they do not preserve a vmalloc mapping. tpacket_destruct_skb() currently drops the pending reference before writing the timestamp and TP_STATUS_AVAILABLE to the frame. Move the decrement after those stores. The smp_wmb() in __packet_set_status() orders the frame stores before the decrement. Also recheck pending TX frames under pg_vec_lock before non-closing ring replacement, so a racing send cannot add a pending skb between the initial check and the ring swap. Ring allocation can produce a mixture of page-backed and vmalloc-backed blocks. Allocate deferred-work storage during TX ring setup when the first vmalloc-backed block is encountered, and keep its pointer in the pg_vec allocation header. If allocation fails, return -ENOMEM from ring setup. On socket close, a non-NULL pointer identifies a vmalloc-backed vector without a scan. If TX skbs remain, defer the whole vector to system_long_wq. After pg_vec is detached, a late destructor can skip the pending decrement. Use socket write-memory accounting as the deferred lifetime gate instead: an skb remains charged through its final sock_wfree(), after all ring-frame accesses. The delayed work retains a socket reference and reschedules itself until no TX skbs remain. Move pending_refcnt release to packet_sock_destruct() so late skb destructors and deferred cleanup can safely use it after packet_release(). Page-backed teardown remains synchronous, and no lock is added to the TX completion hot path. | medium | 2026-09-21 |
| CVE-2026-80836 | In the Linux kernel, the following vulnerability has been resolved: crypto: virtio - bound the akcipher result length virtio_crypto_dataq_akcipher_callback() sets the result length from the device-reported response length without bounding it to the destination buffer, which was allocated for the original request length. sg_copy_from_buffer() then reads that many bytes from the destination buffer; a backend reporting a larger length over-reads adjacent kernel heap into the caller's scatterlist (an out-of-bounds read). Clamp the reported length to the originally requested destination length. A conforming device reports no more than that, so valid results are unaffected. | high | 2026-09-21 |
| CVE-2026-80734 | In the Linux kernel, the following vulnerability has been resolved: btrfs: initialize inode mapping flags for cached inodes [BUG] When running generic/795 with 8K block size, 4K page size, the test always fails, triggering some ASSERT()s related to folio size: 795 (241074): drop_caches: 3 assertion failed: IS_ALIGNED(start, blocksize) && IS_ALIGNED(end + 1, blocksize), in extent_io.c:1404 (blocksize=8192 root=262 ino=258 start=16826368 end=16830463 mapping min order=0) ------------[ cut here ]------------ kernel BUG at extent_io.c:1404! Oops: invalid opcode: 0000 [#1] SMP CPU: 8 UID: 0 PID: 241105 Comm: fsstress Tainted: G OE 7.2.0-rc5-custom+ #442 PREEMPT(full) f4bfb352566f3949f29c233ce6f735050a03b245 Tainted: [O]=OOT_MODULE, [E]=UNSIGNED_MODULE Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS unknown 02/02/2022 RIP: 0010:assert_folio_range.cold+0x3d/0x3f [btrfs] Call Trace: <TASK> btrfs_read_folio+0x9e/0x170 [btrfs 4cd1dd93b341b8ef766643f9512f4a86259567a3] prepare_one_folio.constprop.0+0x104/0x2a0 [btrfs 4cd1dd93b341b8ef766643f9512f4a86259567a3] btrfs_buffered_write+0x285/0xa50 [btrfs 4cd1dd93b341b8ef766643f9512f4a86259567a3] btrfs_do_write_iter+0x1aa/0x210 [btrfs 4cd1dd93b341b8ef766643f9512f4a86259567a3] iter_file_splice_write+0x31a/0x540 direct_splice_actor+0x53/0x170 splice_direct_to_actor+0xe9/0x240 do_splice_direct+0x76/0xb0 vfs_copy_file_range+0x1fd/0x630 __x64_sys_copy_file_range+0xf9/0x220 do_syscall_64+0xe1/0x790 entry_SYSCALL_64_after_hwframe+0x4b/0x53 </TASK> ---[ end trace 0000000000000000 ]--- The ASSERT() itself is added by a later patch. The crash is triggered with that new debug patch, and without this fix. [CAUSE] In the above case, the start 16826368 is properly 8K aligned, but the end (16830463 + 1) is not 8K aligned. Furthermore the mapping's minimal folio order is 0, not the expected 1 for 8K block size with 4K page size. So this means some inodes do not have btrfs_set_inode_mapping_order() called on it. The missing btrfs_set_inode_mapping_order() call happens for cached inodes, through the following events: - btrfs_create_new_inode() called for inode X Which properly sets minimal folio order for the VFS inode. - btrfs_update_inode() called for inode X Which calls btrfs_delayed_update_inode() to create a delayed_node into root->delayed_nodes xarray. - Drop cache/memory pressure, evicting in-memory inode X Which evicted the inode X, but delayed_node is still in root->delayed_nodes for future reuse. - btrfs_iget() for inode X called again btrfs_iget() |- btrfs_iget_locked() | |- iget5_locked_rcu() | Which creates a new vfs_inode for btrfs, whose mapping still | has the minimal order as 0. | |- btrfs_read_locked_inode() |- btrfs_fill_inode() | |- btrfs_get_delayed_node() | Which found out the previous node, and use that delayed | node to initialize the new inode. | |- filled = true; |- if (filled) goto cache_index; Which skips the btrfs_update_inode_mapping_flags() and btrfs_set_inode_mapping_order() calls. So the inode still has minimal folio order set as 0, not the required 1. Thus later page cache read will get a folio whose size is smaller than block size, as the mapping has its minimal folio order set as 0 not 1, then trigger the ASSERT(). [FIX] Move the btrfs_update_inode_mapping_flags() and btrfs_set_inode_mapping_order() calls under cache_index label, so that the mapping flags and minimal folio order is always set no matter if we have a cached inode. | high | 2026-09-21 |
| CVE-2026-80685 | In the Linux kernel, the following vulnerability has been resolved: mm/util: don't read __page_2 for order-1 folios in snapshot_page() snapshot_page() currently reads __page_2 after checking nr_pages > 1, but it should only do so when nr_pages > 2. If an order-1 folio is allocated at the end of a vmemmap section, __page_2 will not exist and reading it will cause a fault. During DLPAR memory remove on a 22 TB ppc64le LPAR, snapshot_page() oopsed on the page isolation path while reading an order-1 folio's __page_2 from an adjacent absent section (unmapped vmemmap). Fix this to avoid reading memmap that doesn't exist (e.g., a vmemmap hole). | high | 2026-09-21 |
| CVE-2026-80521 | In the Linux kernel, the following vulnerability has been resolved: af_unix: Unlink scc_entry in unix_del_edge(). Kyle Zeng reported that GC could free a dead SCC partially. The scenario is as follows: 1) Create two SCCs: X -. A <-> B ^--' 2) Run the following concurrently: 2-1) send() sk-B to sk-B from sk-X 2-2) close() both A and B At 2-1), there is a small window where unix_add_edges() publishes a new edge (B <-> B) to GC but its skb is not queued by skb_queue_tail(). If 2-2) completes before skb_queue_tail() and GC is triggered, it judges A <-> B as dead, but B is not freed because GC cannot collect the not-yet-queued skb holding the B <-> B edge. X -. A <-> B -. This edge is visible ^--' ^..' but skb is not This itself is not a problem since the next GC run will judge B as dead as well and free it finally. X -. A <.> B -. ^--' ^--' However, X's SCC forces the next GC to call unix_walk_scc_fast(), and it iterates over A through B's scc_entry. Let's unlink scc_entry before freeing the vertex in unix_del_edge(). | high | 2026-09-21 |
| CVE-2026-80219 | Rejected reason: Red Hat Product Security has come to the conclusion that this CVE is not needed. | No Score | 2026-09-21 |
| CVE-2026-80110 | A flaw was found in pki-core. The v2 REST ACL filter selects a tie-breaking permission for colliding literal and wildcard ACL keys using lexicographic string comparison rather than specificity, causing a wildcard-mapped permission to override a more specific literal-mapped permission when both match. In the CA's profile-management REST API this allows a request to POST /v2/profiles/raw -- intended to require Administrator-level profiles.create permission -- to instead be authorized under the lower-privileged profiles.approve permission held by the default Certificate Manager Agents group. The highest threat from this vulnerability is to confidentiality and integrity of the certificate authority's issuance policy. | high | 2026-09-21 |
| CVE-2026-79920 | Ajenti is a Linux & BSD modular server admin panel. Prior to version 2.2.16, any authenticated user can call /api/core/tasks/start to enqueue InstallPlugin, UnInstallPlugin, or UpgradeAll from plugins/plugins/tasks.py without plugin-management authorization. InstallPlugin and UnInstallPlugin construct a pip package specification from unvalidated name and version fields, and the task worker invokes pip while running as root. A low-privileged user can therefore select or manipulate a package installed with root privileges and can install, remove, or upgrade plugins without administrative permission, resulting in root code execution and full host compromise. This issue is fixed in version 2.2.16. | critical | 2026-09-21 |
| CVE-2026-79919 | MaxKB is an open-source AI assistant for enterprise. Prior to version 2.10.6-lts, function-library code running under the LD_PRELOAD sandbox can invoke ctypes.CDLL from an importlib.abc.MetaPathFinder callback so the dlopen call-stack heuristic sees a Python import frame, then use unhooked dlsym with RTLD_NEXT to resolve glibc's real syscall and bypass the sandbox syscall blacklist. An authenticated workspace member can consequently read or write files, execute processes, or access networks as the sandbox user. This issue is fixed in version 2.10.6-lts. | medium | 2026-09-21 |
| CVE-2026-79918 | MaxKB is an open-source AI assistant for enterprise. Prior to version 2.10.6-lts, the ToolExecutor LD_PRELOAD sandbox hooks execve, execvpe, and execveat to prevent subprocess creation but does not hook fexecve. An authenticated attacker able to execute tool code can call fexecve to start a process outside the sandbox's intended subprocess policy. This issue is fixed in version 2.10.6-lts. | medium | 2026-09-21 |
| CVE-2026-79917 | MaxKB is an open-source AI assistant for enterprise. In 2.7.0 through 2.10.4-lts, POST /chat/api/{application_id}/chat/{chat_id}/share_chat verifies that a conversation exists but does not verify that it belongs to the authenticated chat_user_id or to the application bound to the caller's token. An attacker with any chat token and a known victim chat_id can create an unauthenticated public ChatShareLink exposing the victim's conversation and can create PublicFileAccess state that makes associated files retrievable without credentials, with no available revoke path. No fixed version is available as of this review. | medium | 2026-09-21 |
| CVE-2026-79916 | MaxKB is an open-source AI assistant for enterprise. Prior to 2.10.5-lts, authenticated workspace members can inject control characters into AWS Bedrock access_key_id and secret_access_key fields that _update_aws_credentials writes to /root/.aws/credentials without safe parsing. An attacker can append a new AWS profile containing credential_process, then select that profile during a later model-validation request so botocore executes an attacker-controlled command as root. This vulnerability is fixed in 2.10.5-lts. | critical | 2026-09-21 |
| CVE-2026-79362 | Certain Woltlab products are affected by RCE via Cache Poisoning. WCF >= 6.1.0 until < 6.1.23 and WCF >= 6.2.0 until < 6.2.6. An authenticated low-privileged user can inject PHP into executable cache files generated by WoltLab Suite Core. Attacker-controlled data can terminate the nowdoc prematurely and inject arbitrary PHP Code. | high | 2026-09-21 |
| CVE-2026-79320 | Stencil core 4.43.5 contains a DOM-based cross-site scripting (XSS) vulnerability in the component runtime. When a downstream application enables the experimental slot fixes option and uses scoped components, assigning a string to the textContent property of such a component's host element causes the value to be parsed as HTML instead of being inserted as text. If an application writes attacker-controlled data to these host elements, the data can be interpreted as markup and script can execute in the context of the application's origin. | medium | 2026-09-21 |
| CVE-2026-79319 | Stencil core 4.43.5 is vulnerable to Incorrect Access Control. | critical | 2026-09-21 |
| CVE-2026-79318 | web2py 3.2.2-stable (commit a7330a2bf21219fa77860b6665de927dd4f98e6d) is vulnerable to Directory Traversal in read_file()/write_file() (applications/admin/controllers/webservices.py). | high | 2026-09-21 |
| CVE-2026-79317 | A session invalidation flaw exists in x-ui 0.3.2. The full user object is stored in a client-side signed cookie, and authentication only checks that a user object can be retrieved from the cookie without re-validating against the database or any session version. When an administrator changes the username or password, previously issued session cookies are not revoked, so an attacker who holds a pre-change admin cookie can continue accessing and operating the management interface after the credentials have been rotated. | critical | 2026-09-21 |
| CVE-2026-79316 | An improper access control vulnerability exists in x-ui 0.3.2. Any authenticated panel user can modify the xray configuration template through the settings interface and trigger a panel restart, causing the xray management gRPC service, which is bound to loopback by default, to be regenerated and bound to non-loopback addresses. This expands the reachable surface of the management interface beyond its intended local-only boundary. | high | 2026-09-21 |
| CVE-2026-79079 | An issue in CrossWire Xiphos <= 4.3.2 allows a local attacker to execute arbitrary code via the src/main/url.cc and src/gtk/menu_popup.c components | high | 2026-09-21 |
| CVE-2026-78847 | An issue in gray-matter All versions (verified on 4.0.3) allows the JavaScript engine in lib/engines.js using eval() to parse front matter when language is js/javascript.This allows arbitrary code execution. | critical | 2026-09-21 |
| CVE-2026-78806 | An issue in Matter Standard Specification-Implementation gap v1.5.1 Matter Project Chip V1.5.1 allows a local attacker to obtain sensitive information via the PerformCommissioningStep function in the ChipDeviceController.cpp component | medium | 2026-09-21 |
| CVE-2026-78510 | Heap-based buffer overflow in Microsoft Office allows an unauthorized attacker to execute code over a network. | critical | 2026-09-21 |
| CVE-2026-78376 | A flaw was found in WebKitGTK. Processing malicious web content can cause a use-after-free issue due to improper memory handling and result in memory corruption. | high | 2026-09-21 |
| CVE-2026-77972 | Time-of-check Time-of-use (TOCTOU) Race Condition in Slab safeurl allows an attacker who controls a hostname's DNS responses to reach internal network destinations that validation rejected. Validation returns a verdict and not the address it approved, so the HTTP clients the library ships receive the original hostname and resolve it a second time when the request is made. An attacker who controls the authoritative DNS for a name can answer the first lookup with a permitted address and the second with a blocked one, and the request then reaches a destination validation never approved. The same window opens without an attacker whenever a name legitimately resolves to different addresses across lookups, such as short record lifetimes or rotation between several addresses. This issue affects safeurl: from 0.1.0 onward. | critical | 2026-09-21 |
| CVE-2026-77866 | Server-Side Request Forgery (SSRF) vulnerability in Slab safeurl allows an attacker who controls a validated URL to reach internal network destinations the library is configured to block. Only IPv4 addresses are matched against the reserved ranges and the blocklist. Every other address is treated as matching nothing, so a destination that is rejected in its IPv4 form is accepted when written as an IPv6 address, IPv6 entries in the blocklist never match, and a host that resolves to no IPv4 address is accepted regardless of where it points. Deployments that rely on the allowlist instead are unaffected, because there an unmatched address is rejected. This issue affects safeurl: from 0.1.0 onward. | critical | 2026-09-21 |
| CVE-2026-77820 | The WPComplete plugin for WordPress is vulnerable to Stored Cross-Site Scripting via 'empty' Shortcode Attribute in all versions up to, and including, 2.9.9.0 due to insufficient input sanitization and output escaping. This makes it possible for authenticated attackers, with contributor-level access and above, to inject arbitrary web scripts in pages that will execute whenever a user accesses an injected page. This requires the premium version of the software in order to exploit. Please note this only affects the pro version. | medium | 2026-09-21 |
| CVE-2026-77610 | Semantic MediaWiki is a free, open-source extension to MediaWiki that lets users store and query data within the wiki's pages. Prior to version 7.2.0, query debug output (`format=debug`, or the `debug` request parameter on `Special:Ask`) is assembled by `SMW\Query\DebugFormatter` and emitted as raw HTML. Several of its sinks apply no output-context encoding, so attacker-controlled query input is reflected into the page without escaping. On `Special:Ask` the resulting string is concatenated into the page and sent through `OutputPage::addHTML`, never through the MediaWiki parser or Sanitizer. No special user right is required; an anonymous request suffices. This is a reflected XSS: the payload is taken from the request and echoed in the same response. Exploitation requires the query condition to target a text/blob-typed property (whose value is re-serialized verbatim); the predefined `_txt` properties (`Text`, etc.) that ship on every install satisfy this, so no attacker-created content is needed. Version 7.2.0 patches the issue. | medium | 2026-09-21 |
| CVE-2026-77608 | Semantic MediaWiki is a free, open-source extension to MediaWiki that lets users store and query data within the wiki's pages. Prior to version 7.2.0, when the `value` parameter was reflected back into rendered output and error messaging paths without enough output-context encoding. Version 7.2.0 fixes the issue. | medium | 2026-09-21 |
| CVE-2026-77582 | Tinyauth is an authentication and authorization server. Prior to 5.1.0, Tinyauth exposes a remotely observable timing difference between authentication attempts for existing and nonexistent local usernames. internal/controller/user_controller.go loginHandler and internal/middleware/context_middleware.go basicAuth return quickly after internal/service/auth_service.go reports a missing user, while an existing user causes bcrypt password verification work. Repeated measurements can therefore disclose valid usernames and support targeted credential attacks. This issue is fixed in version 5.1.0. | medium | 2026-09-21 |
