Export limit exceeded: 376224 CVEs match your query. Please refine your search to export 10,000 CVEs or fewer.
Export limit exceeded: 376224 CVEs match your query. Please refine your search to export 10,000 CVEs or fewer.
Search
Search Results (376224 CVEs found)
| CVE | Vendors | Products | Updated | CVSS v3.1 |
|---|---|---|---|---|
| CVE-2026-68251 | 1 Linux | 1 Linux Kernel | 2026-08-10 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu/sdma6.0: replace BUG_ON() with WARN_ON() There's no need to crash the kernel for these cases. (cherry picked from commit c17a508a7d652da3728f8bbc481bfffe96d65a87) | ||||
| CVE-2026-68252 | 1 Linux | 1 Linux Kernel | 2026-08-10 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu/sdma7.0: replace BUG_ON() with WARN_ON() There's no need to crash the kernel for these cases. (cherry picked from commit 9723a8bed3aa251a26bee4583bac9d8fb064dd44) | ||||
| CVE-2026-68253 | 1 Linux | 1 Linux Kernel | 2026-08-10 | 6.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: drm/i915/hdcp: check streams[] bounds before overflow The data->streams[] overflow check is done after the buffer overflow has already happened. Move the overflow check before the write. Side note, emitting a warning splat with a backtrace might be overkill here, but prefer not changing the behaviour other than not doing the overrun. Discovered using AI-assisted static analysis confirmed by Intel Product Security. (cherry picked from commit 9284ab3b6e776c315883ac2611283d263c9460fd) | ||||
| CVE-2026-68255 | 1 Linux | 1 Linux Kernel | 2026-08-10 | 6.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: drm/virtio: bound EDID block reads to the response buffer virtio_get_edid_block() validates the read offset only against the device-supplied resp->size field, never against the fixed-size resp->edid array. The EDID block index is driven by the device-supplied extension count, so a malicious virtio-gpu backend can advertise a large size together with a high block count and read far past the array into adjacent kernel memory, which is then surfaced in the parsed EDID (an out-of-bounds read / info leak). Also reject any read whose end exceeds the size of the edid array. Conforming EDID responses stay within the array and are unaffected. | ||||
| CVE-2026-17017 | 2026-08-10 | 8.1 High | ||
| The CubeWP Framework WordPress plugin before 1.1.31 does not properly sanitize and escape a parameter before using it in a SQL statement through an AJAX action, and does not include a capability check on that action, allowing users with Subscriber-level access and above to perform SQL injection attacks. | ||||
| CVE-2026-13079 | 1 Watchguard | 42 Firebox M270, Firebox M290, Firebox M295 and 39 more | 2026-08-10 | 7.8 High |
| A local privilege escalation vulnerability in the WatchGuard Mobile VPN with SSL client for Windows allows a local attacker to escalate their privileges to NT AUTHORITY\SYSTEM on the machine where the client is installed. This issue affects the Mobile VPN with SSL client for Windows up to and including 2026.2. | ||||
| CVE-2026-13701 | 2026-08-10 | 4.8 Medium | ||
| The Advanced Excerpt WordPress plugin before 4.5 does not sanitise and escape one of its settings before outputting it on the front end of the site, which could allow administrators (including those without the unfiltered_html capability, such as on multisite) to perform Stored Cross-Site Scripting attacks that execute in the context of any visitor viewing affected pages. | ||||
| CVE-2026-8247 | 1 Watchguard | 1 Fireware Os | 2026-08-10 | N/A |
| An Out-of-bounds Write vulnerability in WatchGuard Fireware OS may allow an unauthenticated attacker on the same local network segment to execute arbitrary code. This vulnerability affects Fireware OS 11.0 up to and including 11.12.4_Update1, 12.0 up to and including 12.12 and 2025.1 up to and including 2026.2. | ||||
| CVE-2026-17022 | 2 Salonbookingsystem, Wordpress | 2 Salon Booking System, Wordpress | 2026-08-10 | 7.5 High |
| The Salon Booking System WordPress plugin through 10.30.33 does not properly validate a booking's ownership token before loading it in its booking-wizard confirmation steps, allowing unauthenticated attackers to disclose other customers' booking records, including personal information, by supplying a sequential booking identifier. | ||||
| CVE-2026-13728 | 1 Watchguard | 38 Firebox M270, Firebox M290, Firebox M295 and 35 more | 2026-08-10 | 4.4 Medium |
| In exception circumstances, WatchGuard Fireware OS on a FireCluster may use a hard-coded encryption key to encrypt saved credentials for Access Portal resources. This vulnerability does not affect devices that do not support the Access Portal feature or standalone Fireboxes not deployed in a FireCluster. | ||||
| CVE-2026-16535 | 2 Link Library Project, Wordpress | 2 Link Library, Wordpress | 2026-08-10 | 6.1 Medium |
| The Link Library WordPress plugin before 7.9.4 does not sanitise and escape a parameter before reflecting it back in a response, allowing unauthenticated attackers to perform Reflected Cross-Site Scripting attacks against users who can be tricked into performing an action. | ||||
| CVE-2026-13084 | 1 Watchguard | 1 Fireware Os | 2026-08-10 | N/A |
| A null pointer dereference vulnerability in WatchGuard Fireware OS may allow a remote unauthenticated attacker to create a denial-of-service (DoS) condition by sending specially crafted IKEv2 messages. This vulnerability affects both the Mobile User VPN with IKEv2 and the Branch Office VPN using IKEv2 when configured with a dynamic gateway peer. This vulnerability affects Fireware OS 11.10.2 up to and including 11.12.4_Update1, 12.0 up to and including 12.12 and 2025.1 up to and including 2026.2 | ||||
| CVE-2026-68130 | 1 Linux | 1 Linux Kernel | 2026-08-10 | 6.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: ksmbd: defer destroy_previous_session() until after NTLM authentication In ntlm_authenticate(), destroy_previous_session() is called using a user pointer resolved from the client-supplied NTLM blob username field before the NTLMv2 response is validated. An authenticated attacker can set the NTLM blob username to match a victim account and set PreviousSessionId to the victim's session ID; destroy_previous_session() destroys the victim's session while ksmbd_decode_ntlmssp_auth_blob() subsequently rejects the request with -EPERM. Move destroy_previous_session() and the prev_id assignment to after ksmbd_decode_ntlmssp_auth_blob() returns success and use sess->user rather than the pre-authentication lookup result. This matches the ordering already used by krb5_authenticate(), where destroy_previous_session() is called only after ksmbd_krb5_authenticate() returns success. | ||||
| CVE-2026-68131 | 1 Linux | 1 Linux Kernel | 2026-08-10 | 5.3 Medium |
| In the Linux kernel, the following vulnerability has been resolved: rbd: Reset positive result codes to zero in object map update path In a reply message to an RBD request, a positive result code indicates a data payload, which is not allowed for writes. While rbd_osd_req_callback() already resets a positive result code for writes to zero, rbd_object_map_callback() does not. This allows a corrupted reply to an object map update to trigger the rbd_assert(*result < 0) in __rbd_obj_handle_request(). This happens, because rbd_object_map_callback() calls rbd_obj_handle_request() -> __rbd_obj_handle_request() and passes this positive result code. From __rbd_obj_handle_request(), rbd_obj_advance_write() is called, which leaves the positive result code unchanged and returns true. Therefore, the if(done && *result) branch is executed in __rbd_obj_handle_request() and the assertion triggers. This patch fixes the issue by adjusting the logic in the rbd_object_map_callback() path. A positive result code for an object map update is now reset to zero (similar to rbd_osd_req_callback()), and the message is subsequently handled the same way as if the result code was zero from the beginning. Additionally, a WARN_ON_ONCE() is added for this case. | ||||
| CVE-2026-68132 | 1 Linux | 1 Linux Kernel | 2026-08-10 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: super: fix emergency thaw deadlock on frozen block devices do_thaw_all_callback() calls bdev_thaw() while holding sb->s_umount exclusively. If the block device was frozen via bdev_freeze() dropping the last block layer freeze reference calls fs_bdev_thaw() which reacquires s_umount: do_thaw_all_callback(sb) super_lock_excl(sb) # holds sb->s_umount bdev_thaw(sb->s_bdev) mutex_lock(&bdev->bd_fsfreeze_mutex) # bd_fsfreeze_count drops 1 -> 0 bd_holder_ops->thaw == fs_bdev_thaw get_bdev_super(bdev) bdev_super_lock(bdev, true) super_lock(sb, true) down_write(&sb->s_umount) # same task: deadlock The emergency thaw worker deadlocks against itself holding both s_umount and bd_fsfreeze_mutex. That fscks any subsequent unmount, freeze, or thaw of that filesystem and block device. [ 81.878470] sysrq: Show Blocked State [ 81.880140] task:kworker/0:1 state:D stack:0 pid:11 tgid:11 ppid:2 task_flags:0x4208060 flags:0x00080000 [ 81.884876] Workqueue: events do_thaw_all [ 81.886656] Call Trace: [ 81.887759] <TASK> [ 81.888763] __schedule+0x579/0x1420 [ 81.890372] schedule+0x3a/0x100 [ 81.891794] schedule_preempt_disabled+0x15/0x30 [ 81.893848] rwsem_down_write_slowpath+0x1ea/0x900 [ 81.895191] ? __pfx_do_thaw_all_callback+0x10/0x10 [ 81.896528] down_write+0xbd/0xc0 [ 81.897505] super_lock+0x91/0x180 [ 81.898457] ? __mutex_lock+0xa99/0x1140 [ 81.900748] ? __mutex_unlock_slowpath+0x1f/0x400 [ 81.902069] bdev_super_lock+0x5b/0x150 [ 81.903132] get_bdev_super+0x10/0x60 [ 81.904042] fs_bdev_thaw+0x23/0xf0 [ 81.904755] bdev_thaw+0x82/0x100 [ 81.905484] do_thaw_all_callback+0x2c/0x50 [ 81.906298] __iterate_supers+0x5d/0x130 [ 81.907067] do_thaw_all+0x20/0x40 [ 81.907739] process_one_work+0x206/0x5e0 [ 81.908545] worker_thread+0x1e2/0x3c0 [ 81.909339] ? __pfx_worker_thread+0x10/0x10 [ 81.910171] kthread+0xf4/0x130 [ 81.910799] ? __pfx_kthread+0x10/0x10 [ 81.911528] ret_from_fork+0x2e2/0x3b0 [ 81.912259] ? __pfx_kthread+0x10/0x10 [ 81.913010] ret_from_fork_asm+0x1a/0x30 [ 81.913806] </TASK> bdev_super_lock() even documents the violated requirement with lockdep_assert_not_held(&sb->s_umount). Acquiring bd_fsfreeze_mutex under s_umount also inverts the bd_fsfreeze_mutex vs. s_umount ordering established by bdev_{freeze,thaw}() and can thus ABBA against a concurrent block-layer freeze even when the recursive path isn't hit. Fix this by not holding s_umount around the bdev_thaw() loop at all. Pin the superblock with an active reference instead as filesystems_freeze_callback() does. The active reference keeps the superblock from being shut down and so ->s_bdev stays valid without holding s_umount. The block-layer-held freeze is dropped by fs_bdev_thaw() with FREEZE_MAY_NEST | FREEZE_HOLDER_USERSPACE exactly as a regular unfreeze would and thaw_super_locked() handles filesystem-level freezes as before. The emergency thaw path has deadlocked like this in one form or another for a long long time but the current exclusively-held shape dates back to commit [1] where thaw_bdev() already ended in thaw_super() with s_umount held by do_thaw_all_callback(). | ||||
| CVE-2026-68133 | 1 Linux | 1 Linux Kernel | 2026-08-10 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: ice: fix PTP Call Trace during PTP release If a PF reset occurs when the PTP state is ICE_PTP_UNINIT, then ice_ptp_rebuild() will update the state to ICE_PTP_ERROR. This will result in the following PTP release call trace during driver unload: kernel BUG at lib/list_debug.c:52! ice_ptp_release+0x332/0x3c0 [ice] ice_deinit_features.part.0+0x10e/0x120 [ice] ice_remove+0x100/0x220 [ice] This was observed when passing PF1 through to a VM. ice_ptp_init() fails because ctrl_pf is NULL and sets the state to ICE_PTP_UNINIT. Fix by detecting the ICE_PTP_UNINIT state in ice_ptp_rebuild() and returning without error, preventing the invalid state transition to ICE_PTP_ERROR. The only valid path to ICE_PTP_ERROR is from ICE_PTP_RESETTING after a failed rebuild. | ||||
| CVE-2026-68135 | 1 Linux | 1 Linux Kernel | 2026-08-10 | 5.9 Medium |
| In the Linux kernel, the following vulnerability has been resolved: net: hip04: fix RX buffer leak on build_skb failure When build_skb() fails in hip04_rx_poll(), the driver jumps to the refill path without releasing the current RX buffer and its DMA mapping. Installing a replacement buffer then overwrites the slot references and leaks both resources. Keep the current slot intact and return budget so NAPI retries the same buffer. Also free a newly allocated RX fragment when dma_map_single() fails. This issue was found by an in-house static analysis tool. | ||||
| CVE-2026-68142 | 1 Linux | 1 Linux Kernel | 2026-08-10 | 5.7 Medium |
| In the Linux kernel, the following vulnerability has been resolved: geneve: require CAP_NET_ADMIN in the device netns for changelink A tunnel changelink() operates on at most two netns, dev_net(dev) and the sticky underlay netns geneve->net. They differ once the device is created in or moved to a netns other than the one the request runs in. The rtnl changelink path checks CAP_NET_ADMIN only against dev_net(dev), so a caller privileged there but not in geneve->net can rewrite a geneve device whose underlay lives in geneve->net. geneve_changelink() applies the new configuration against geneve->net: geneve_link_config() and the geneve_quiesce()/geneve_unquiesce() pair reopen the underlay sockets in that netns (geneve_sock_add() uses geneve->net), so the same reasoning as the tunnel changelink series applies here. Gate geneve_changelink() with rtnl_dev_link_net_capable(), at the top of the op before any attribute is parsed, matching ipgre_changelink() and the rest of the "require CAP_NET_ADMIN in the device netns for changelink" series. Found by 0sec automated security-research tooling (https://0sec.ai). | ||||
| CVE-2026-68146 | 1 Linux | 1 Linux Kernel | 2026-08-10 | 5.3 Medium |
| In the Linux kernel, the following vulnerability has been resolved: ftrace: Add global mutex to serialize trace_parser access In ftrace, the trace_parser structure is allocated and initialized when a trace file is opened, and is subsequently used across write and release handlers to parse user input. The affected handler paths and their specific functions are: - Open paths: ftrace_regex_open(), ftrace_graph_open() - Write paths: ftrace_regex_write(), ftrace_graph_write() - Release paths: ftrace_regex_release(), ftrace_graph_release() If userspace opens a trace file descriptor and shares it across multiple threads, concurrent write calls will race on the parser's internal state, specifically the 'idx', 'cont', and 'buffer' fields, leading to corrupted input or undefined behavior. Fix this by adding a global mutex, parser_lock, to serialize all access to trace_parser across write and release paths, preventing concurrent corruption of parser state. | ||||
| CVE-2026-68149 | 1 Linux | 1 Linux Kernel | 2026-08-10 | 3.3 Low |
| In the Linux kernel, the following vulnerability has been resolved: fs: preserve ACL_DONT_CACHE state in forget_cached_acl() The ACL_DONT_CACHE state is meant to be a constant state for the inode for filesystems that want to opt out of posix acl caching. Commit facd61053cff1 ("fuse: fixes after adapting to new posix acl api") used this facility to opt out of posix acl caching for fuse inodes with fuse server that does not negotiate FUSE_POSIX_ACL (fc->posix_acl). The commit also takes care to gate the forget_all_cached_acls() call in fuse_set_acl() on fc->posix_acl because there is no need for it, but there are other placed in fuse code which call forget_all_cached_acls() unconditional to fc->posix_acl and those cause the loss of the ACL_DONT_CACHE state. This is not only a functional bug. Properly timed, a get_acl() from this fuse filesystem can return a stale cached value, as was observed in tests, because set_acl() does not invalidate the unintentional acl cache. We could fix this in fuse, but it actually makes no sense for the vfs helper forget_cached_acl() to invalidate the ACL_DONT_CACHE state, so let it not do that to fix fuse and future users of ACL_DONT_CACHE. | ||||