Export limit exceeded: 377203 CVEs match your query. Please refine your search to export 10,000 CVEs or fewer.
Search
Search Results (377203 CVEs found)
| CVE | Vendors | Products | Updated | CVSS v3.1 |
|---|---|---|---|---|
| CVE-2026-73519 | 1 Wolfsoftwaresystemsltd | 1 Wolfstack | 2026-08-13 | 9.8 Critical |
| WolfStack before 25.9.2 contains a hard-coded cluster-authentication secret compiled into every build and published as a constant in src/auth/mod.rs, allowing remote unauthenticated attackers to bypass authentication by supplying this value in the X-WolfStack-Secret header to the require_auth() gate without any session, API key, or user account. Attackers can reach an affected node's management port to enumerate all Docker and LXC containers on the host and execute arbitrary commands as root inside any container via the POST /api/containers/{runtime}/{id}/exec endpoint. | ||||
| CVE-2026-49481 | 1 Seriousm4x | 1 Upsnap | 2026-08-13 | 9.6 Critical |
| UpSnap is a wake on lan web app. Versions prior to 5.4.0 have an OS command injection vulnerability in the UpSnap’s device management functionality due to the presence of unsafe shell command template interpolation using the ip and the mac fields. User-controlled values can be inserted into the wake_cmd and shutdown_cmd templates and executed via /bin/sh -c (Linux) or cmd /C (Windows) without sanitization, resulting in an authenticated Remote Code Execution (RCE). A low-privileged user with permission to create or edit devices can execute arbitrary operating system commands on the UpSnap hosted server. Version 5.4.0 patches the issue. | ||||
| CVE-2026-50544 | 1 Northebridge | 1 Luminalshine | 2026-08-13 | 6.3 Medium |
| NortheBridge/luminalshine is a Sunshine-compatible game stream host for Moonlight. Prior to version 26.05.0-rc4, a latent gap exists on a default install, the file at `src/platform/windows/misc.cpp` lives at `C:\ProgramData\LuminalShine\config\apps.json` and is created by the `SYSTEM` service. Under Windows' default `C:\ProgramData` inheritance, that gives `BUILTIN\Users` only Read+Execute — not writable — so the canonical EoP doesn't actually trigger on a vanilla install. Version 26.05.0-rc4 contains a patch for the issue. As a workaround, use default condition DACLs for `ProgramData`. | ||||
| CVE-2026-19182 | 1 Opennms | 2 Horizon, Meridian | 2026-08-13 | 4.3 Medium |
| An incorrect authorization check in the v2 Alarm REST API in OpenNMS Meridian and Horizon allows a low-privileged authenticated user (ROLE_REST) to acknowledge, escalate, or clear alarms recorded as an arbitrary username, and, when also assigned ROLE_READONLY, to modify alarm state despite the read-only restriction. A credential check that should restrict these operations is guarded by an inverted condition, so it never executes for a real (non-blank) username. This can potentially allow an attacker to compromise the integrity of alarm state and audit records. The solution is to upgrade to Meridian 2024.3.12, 2025.0.9 and Horizon 36.0.3 or newer. Meridian and Horizon installation instructions state that they are intended for installation within an organization's private networks and should not be directly accessible from the Internet. | ||||
| CVE-2026-3835 | 2 Buildwps, Wordpress | 2 Prevent Direct Access – Protect Wordpress Files, Wordpress | 2026-08-13 | 5.3 Medium |
| The Prevent Direct Access – Protect WordPress Files plugin for WordPress is vulnerable to unauthorized access of protected files due to insufficient token validation in the `get_advance_file_by_url()` method in all versions up to, and including, 2.8.8.8 The method uses a SQL `LIKE` operator for token lookup without escaping wildcard characters via `$wpdb->esc_like()`. This makes it possible for unauthenticated attackers to bypass the private token requirement by supplying SQL wildcard characters (such as `%`) as the token value, matching any record in the plugin's file table and downloading any protected file. | ||||
| CVE-2026-68126 | 1 Linux | 1 Linux Kernel | 2026-08-13 | 4.1 Medium |
| In the Linux kernel, the following vulnerability has been resolved: mac802154: hold an interface reference across the scan worker mac802154_scan_worker() captures the scanning sub-interface under RCU and then keeps dereferencing sdata->dev after rcu_read_unlock() and outside the rtnl -- in the failure traces, in mac802154_transmit_beacon_req() (skb->dev = sdata->dev), and in the end_scan cleanup. Nothing keeps that netdev alive across the worker iteration. A concurrent DEL_INTERFACE or PHY removal can unregister the interface once the worker drops the rtnl between its two drv_set_channel() sections. unregister_netdevice() frees the netdev asynchronously from netdev_run_todo() with the rtnl already dropped, so neither holding the rtnl nor the per-PHY IEEE802154_IS_SCANNING flag prevents a stale worker iteration from dereferencing the freed netdev -- a KASAN slab-use-after-free, reachable by racing TRIGGER_SCAN against DEL_INTERFACE (both CAP_NET_ADMIN). Pin the netdev with netdev_hold() while the RCU read lock is still held, and release it at every worker exit. | ||||
| CVE-2026-14211 | 2 Ameliabooking, Wordpress | 2 Booking For Appointments And Events Calendar, Wordpress | 2026-08-13 | 3.8 Low |
| The Booking for Appointments and Events Calendar WordPress plugin before 9.7 does not verify that an authenticated employee (provider) is related to the customer whose record is being accessed, allowing any employee with an Employee Panel login to read and modify the stored personal data of any customer by enumerating sequential identifiers. | ||||
| CVE-2026-21072 | 1 Samsung Mobile | 1 Samsung Mobile Devices | 2026-08-13 | N/A |
| Improper input validation in VC1 codec in libsavsvc.so prior to SMR Aug-2026 Release 1 allows local attackers to write out-of-bounds memory. | ||||
| CVE-2026-68084 | 1 Linux | 1 Linux Kernel | 2026-08-13 | N/A |
| In the Linux kernel, the following vulnerability has been resolved: staging: vme_user: fix location monitor leak in tsi148 bridge tsi148_probe() allocates a location monitor resource and links it into tsi148_bridge->lm_resources. The probe error path frees this list, but tsi148_remove() only frees the dma, slave and master resource lists, so the location monitor resource is leaked on device unbind or module unload. Free the lm_resources list in tsi148_remove() as well, before tsi148_bridge is freed. | ||||
| CVE-2026-68110 | 1 Linux | 1 Linux Kernel | 2026-08-13 | 4.7 Medium |
| In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu/sdma4.4.2: replace BUG_ON() with WARN_ON() There's no need to crash the kernel for these cases. (cherry picked from commit fa4f86a148271e325e95287630a3a15a9cd35fdc) | ||||
| CVE-2026-68112 | 1 Linux | 1 Linux Kernel | 2026-08-13 | 4.7 Medium |
| In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu/gfx9.4.3: replace BUG_ON() with WARN_ON() There's no need to crash the kernel for these cases. (cherry picked from commit 5676593d08998d7a6d9e2d51d6b54b3820e3755c) | ||||
| CVE-2026-21069 | 1 Samsung | 1 Mobile Devices | 2026-08-13 | N/A |
| Incorrect conversion between numeric types in VC1 codec in libsavsvc.so prior to SMR Aug-2026 Release 1 allows local attackers to write out-of-bounds memory. | ||||
| CVE-2026-68086 | 1 Linux | 1 Linux Kernel | 2026-08-13 | 7.0 High |
| In the Linux kernel, the following vulnerability has been resolved: mm/khugepaged: write all dirty file folios when collapsing [There is no upstream commit, as this code was removed by upstream commit 044925f9b565 ("mm: fs: remove filemap_nr_thps*() functions and their users")] As-is, khugepaged and writable-file opening exclude each other. A file cannot be open writeable and have THPs (because the filesystem is not aware of them). khugepaged will never collapse file pages for files that are opened writeable. On an open(O_RDWR/O_WRONLY), the page cache for that particular file is dropped. This is fine because nothing could've been dirtied. However, there is an edge-case: collapse_file() might not be able to coexist with concurrent writers, but it can coexist with dirty folios (from previous writers). Therefore, the following can happen: open(file, O_RDWR) write(file) close(file) madvise(file_mapping, MADV_COLLAPSE, some non-dirty range) open(file, O_RDWR) nr_thps > 0 truncate_inode_pages() /* THPs are cleared out, but so are the dirty folios */ When this edge-case happens, there is data loss, as the dirty folios are fully discarded. Fix it by fully writing back the page cache (and waiting) when collapsing file THPs. Doing so provides the guarantee that no dirty folio will be observed while there are active THPs. To fully ensure this is safe, the invalidate_lock needs to be held while doing the writeout, so that do_dentry_open()'s page cache truncation excludes this write-and-wait. As a side effect, move the nr_thps counter bumping outside the i_pages lock. This is correct since the counter itself is an atomic_t and the producer <-> consumer correctness is provided by a full memory barrier: smp_mb() in collapse_file()/memory barrier implied by full ordering in get_write_access() -> atomic_inc_unless_negative(). | ||||
| CVE-2026-68087 | 1 Linux | 1 Linux Kernel | 2026-08-13 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: HID: wacom: use GFP_ATOMIC in wacom_wac_queue_flush() wacom_wac_queue_flush() is called via the .raw_event callback (wacom_raw_event → wacom_wac_pen_serial_enforce → wacom_wac_queue_flush). For USB HID devices, this callback is invoked from hid_irq_in(), which is a URB completion handler running in atomic context. Using GFP_KERNEL in this path can sleep, leading to a "scheduling while atomic" bug. Use GFP_ATOMIC instead. The existing code already handles allocation failure by skipping the fifo entry and continuing. | ||||
| CVE-2026-68089 | 1 Linux | 1 Linux Kernel | 2026-08-13 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: iio: core: fix uninitialized data in debugfs If *ppos is non-zero then simple_write_to_buffer() will not initialize the start of buf[]. Non zero values for *ppos aren't going to work anyway. Test for them at the start of the function and return -EINVAL. | ||||
| CVE-2026-68090 | 1 Linux | 2 Kernel, Linux Kernel | 2026-08-13 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: debugobjects: Plug race against a concurrent OOM disable syzbot reported a puzzling splat: WARNING: kernel/time/hrtimer.c:443 at stub_timer+0xa/0x20 stub_timer() is installed as timer callback function in hrtimer_fixup_assert_init(), which is invoked when debug_object_assert_init() can't find a shadow object. In that case debug objects emits a warning about it before invoking the fixup. Though the provided console log lacks this warning and instead has the following a few seconds before the splat: ODEBUG: Out of memory. ODEBUG disabled So the object was looked up in debug_object_assert_init() and the lookup failed due a concurrent out of memory situation which disabled debug objects and freed the shadow objects: debug_object_assert_init() if (!debug_objects_enabled) return; obj = alloc(); if (!obj) { // Out of memory debug_objects_enabled = false; free_objects(); obj = lookup_or_alloc(); // The lookup failed because the other side // removed the objects, so this returns // an error code as the object in question // is not statically initialized if (!IS_ERR_OR_NULL(obj)) return; if (!obj) { debug_oom(); return; } print(...) if (!debug_objects_enabled) return; fixup(...) The debug object splat is skipped because debug_objects_enabled is false, but the fixup callback is invoked unconditionally, which makes the timer disfunctional. This is only a problem in debug_object_assert_init() and debug_object_activate() as both have to handle statically initialized objects and therefore must handle the error pointer return case gracefully. All other places only handle the found/not found case and the NULL pointer return is a signal for OOM. Otherwise they get a valid shadow object. Plug the hole by checking whether debug objects are still enabled before invoking the print and fixup function in those two places. | ||||
| CVE-2026-68092 | 1 Linux | 1 Linux Kernel | 2026-08-13 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: time/jiffies: Register jiffies clocksource before usage Teddy reported that a XEN HVM has a long boot delay, which was bisected to the recent enhancements to the negative motion detection. It turned out that the jiffies clocksource is used in early boot before it is registered, which leaves the max_delta_raw field at zero. That causes the read out to be clamped to the max delta of 0, which means time is not making progress. Cure it by ensuring that it is initialized before its first usage in timekeeping_init(). | ||||
| CVE-2026-68113 | 1 Linux | 1 Linux Kernel | 2026-08-13 | 4.1 Medium |
| In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu/gfx12: replace BUG_ON() with WARN_ON() There's no need to crash the kernel for these cases. (cherry picked from commit f952076f76d62f783e8ba4995a7c400d39354ccf) | ||||
| CVE-2026-68109 | 1 Linux | 1 Linux Kernel | 2026-08-13 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu/sdma7.1: replace BUG_ON() with WARN_ON() There's no need to crash the kernel for these cases. (cherry picked from commit c4f230b51cf2d3e7e8b1c800331f3dbed2a9e3f5) | ||||
| CVE-2026-68165 | 1 Linux | 1 Linux Kernel | 2026-08-13 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: mm/damon/core: validate ranges in damon_set_regions() DAMON core logic assumes zero length regions don't exist. However, a few DAMON API callers including DAMON_SYSFS, DAMON_RECLAIM and DAMON_LRU_SORT allow users to set empty monitoring target regions. This could result in WARN_ONCE() on CONFIG_DAMON_DEBUG_SANITY enabled kernel, and divide-by-zero from damon_merge_two_regions(). For example, the WANR_ONCE() can be triggered like below. # grep DAMON_DEBUG_SANITY /boot/config-$(uname -r) # CONFIG_DAMON_DEBUG_SANITY=y # damo start # cd /sys/kernel/mm/damon/admin/kdamonds/0 # echo 0 > contexts/0/targets/0/regions/0/start # echo 0 > contexts/0/targets/0/regions/0/end # echo commit > state # dmesg [....] [ 73.705780] ------------[ cut here ]------------ [ 73.707552] start 0 >= end 0 [ 73.708452] WARNING: mm/damon/core.c:359 at damon_new_region+0x6e/0x80, CPU#1: kdamond.0/758 [...] All DAMON API callers eventually use damon_set_regions() to setup the regions. Add the validation logic in the function. | ||||