Export limit exceeded: 344980 CVEs match your query. Please refine your search to export 10,000 CVEs or fewer.
Search
Search Results (344980 CVEs found)
| CVE | Vendors | Products | Updated | CVSS v3.1 |
|---|---|---|---|---|
| CVE-2026-24957 | 2 Wordpress, Wpchill | 2 Wordpress, Strong Testimonials | 2026-04-16 | 6.5 Medium |
| Missing Authorization vulnerability in WP Chill Strong Testimonials strong-testimonials allows Exploiting Incorrectly Configured Access Control Security Levels.This issue affects Strong Testimonials: from n/a through <= 3.2.20. | ||||
| CVE-2026-24988 | 2 Brian Hogg, Wordpress | 2 The Events Calendar Shortcode & Block, Wordpress | 2026-04-16 | 6.5 Medium |
| Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting') vulnerability in Brian Hogg The Events Calendar Shortcode & Block the-events-calendar-shortcode allows Stored XSS.This issue affects The Events Calendar Shortcode & Block: from n/a through <= 3.1.1. | ||||
| CVE-2026-24995 | 1 Wordpress | 1 Wordpress | 2026-04-16 | 4.3 Medium |
| Missing Authorization vulnerability in Iulia Cazan Latest Post Shortcode latest-post-shortcode allows Exploiting Incorrectly Configured Access Control Security Levels.This issue affects Latest Post Shortcode: from n/a through <= 14.2.0. | ||||
| CVE-2026-24997 | 1 Wordpress | 1 Wordpress | 2026-04-16 | 5.3 Medium |
| Missing Authorization vulnerability in Wired Impact Wired Impact Volunteer Management wired-impact-volunteer-management allows Exploiting Incorrectly Configured Access Control Security Levels.This issue affects Wired Impact Volunteer Management: from n/a through <= 2.8. | ||||
| CVE-2026-25036 | 2 Wordpress, Wpchill | 2 Wordpress, Passster | 2026-04-16 | 6.5 Medium |
| Missing Authorization vulnerability in WP Chill Passster content-protector allows Exploiting Incorrectly Configured Access Control Security Levels.This issue affects Passster: from n/a through <= 4.2.25. | ||||
| CVE-2026-23050 | 1 Linux | 1 Linux Kernel | 2026-04-16 | 7.0 High |
| In the Linux kernel, the following vulnerability has been resolved: pNFS: Fix a deadlock when returning a delegation during open() Ben Coddington reports seeing a hang in the following stack trace: 0 [ffffd0b50e1774e0] __schedule at ffffffff9ca05415 1 [ffffd0b50e177548] schedule at ffffffff9ca05717 2 [ffffd0b50e177558] bit_wait at ffffffff9ca061e1 3 [ffffd0b50e177568] __wait_on_bit at ffffffff9ca05cfb 4 [ffffd0b50e1775c8] out_of_line_wait_on_bit at ffffffff9ca05ea5 5 [ffffd0b50e177618] pnfs_roc at ffffffffc154207b [nfsv4] 6 [ffffd0b50e1776b8] _nfs4_proc_delegreturn at ffffffffc1506586 [nfsv4] 7 [ffffd0b50e177788] nfs4_proc_delegreturn at ffffffffc1507480 [nfsv4] 8 [ffffd0b50e1777f8] nfs_do_return_delegation at ffffffffc1523e41 [nfsv4] 9 [ffffd0b50e177838] nfs_inode_set_delegation at ffffffffc1524a75 [nfsv4] 10 [ffffd0b50e177888] nfs4_process_delegation at ffffffffc14f41dd [nfsv4] 11 [ffffd0b50e1778a0] _nfs4_opendata_to_nfs4_state at ffffffffc1503edf [nfsv4] 12 [ffffd0b50e1778c0] _nfs4_open_and_get_state at ffffffffc1504e56 [nfsv4] 13 [ffffd0b50e177978] _nfs4_do_open at ffffffffc15051b8 [nfsv4] 14 [ffffd0b50e1779f8] nfs4_do_open at ffffffffc150559c [nfsv4] 15 [ffffd0b50e177a80] nfs4_atomic_open at ffffffffc15057fb [nfsv4] 16 [ffffd0b50e177ad0] nfs4_file_open at ffffffffc15219be [nfsv4] 17 [ffffd0b50e177b78] do_dentry_open at ffffffff9c09e6ea 18 [ffffd0b50e177ba8] vfs_open at ffffffff9c0a082e 19 [ffffd0b50e177bd0] dentry_open at ffffffff9c0a0935 The issue is that the delegreturn is being asked to wait for a layout return that cannot complete because a state recovery was initiated. The state recovery cannot complete until the open() finishes processing the delegations it was given. The solution is to propagate the existing flags that indicate a non-blocking call to the function pnfs_roc(), so that it knows not to wait in this situation. | ||||
| CVE-2026-23053 | 1 Linux | 1 Linux Kernel | 2026-04-16 | 7.0 High |
| In the Linux kernel, the following vulnerability has been resolved: NFS: Fix a deadlock involving nfs_release_folio() Wang Zhaolong reports a deadlock involving NFSv4.1 state recovery waiting on kthreadd, which is attempting to reclaim memory by calling nfs_release_folio(). The latter cannot make progress due to state recovery being needed. It seems that the only safe thing to do here is to kick off a writeback of the folio, without waiting for completion, or else kicking off an asynchronous commit. | ||||
| CVE-2026-23066 | 1 Linux | 1 Linux Kernel | 2026-04-16 | 7.8 High |
| In the Linux kernel, the following vulnerability has been resolved: rxrpc: Fix recvmsg() unconditional requeue If rxrpc_recvmsg() fails because MSG_DONTWAIT was specified but the call at the front of the recvmsg queue already has its mutex locked, it requeues the call - whether or not the call is already queued. The call may be on the queue because MSG_PEEK was also passed and so the call was not dequeued or because the I/O thread requeued it. The unconditional requeue may then corrupt the recvmsg queue, leading to things like UAFs or refcount underruns. Fix this by only requeuing the call if it isn't already on the queue - and moving it to the front if it is already queued. If we don't queue it, we have to put the ref we obtained by dequeuing it. Also, MSG_PEEK doesn't dequeue the call so shouldn't call rxrpc_notify_socket() for the call if we didn't use up all the data on the queue, so fix that also. | ||||
| CVE-2026-23070 | 1 Linux | 1 Linux Kernel | 2026-04-16 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: Octeontx2-af: Add proper checks for fwdata firmware populates MAC address, link modes (supported, advertised) and EEPROM data in shared firmware structure which kernel access via MAC block(CGX/RPM). Accessing fwdata, on boards booted with out MAC block leading to kernel panics. Internal error: Oops: 0000000096000005 [#1] SMP [ 10.460721] Modules linked in: [ 10.463779] CPU: 0 UID: 0 PID: 174 Comm: kworker/0:3 Not tainted 6.19.0-rc5-00154-g76ec646abdf7-dirty #3 PREEMPT [ 10.474045] Hardware name: Marvell OcteonTX CN98XX board (DT) [ 10.479793] Workqueue: events work_for_cpu_fn [ 10.484159] pstate: 80400009 (Nzcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 10.491124] pc : rvu_sdp_init+0x18/0x114 [ 10.495051] lr : rvu_probe+0xe58/0x1d18 | ||||
| CVE-2026-23077 | 1 Linux | 1 Linux Kernel | 2026-04-16 | 7.8 High |
| In the Linux kernel, the following vulnerability has been resolved: mm/vma: fix anon_vma UAF on mremap() faulted, unfaulted merge Patch series "mm/vma: fix anon_vma UAF on mremap() faulted, unfaulted merge", v2. Commit 879bca0a2c4f ("mm/vma: fix incorrectly disallowed anonymous VMA merges") introduced the ability to merge previously unavailable VMA merge scenarios. However, it is handling merges incorrectly when it comes to mremap() of a faulted VMA adjacent to an unfaulted VMA. The issues arise in three cases: 1. Previous VMA unfaulted: copied -----| v |-----------|.............| | unfaulted |(faulted VMA)| |-----------|.............| prev 2. Next VMA unfaulted: copied -----| v |.............|-----------| |(faulted VMA)| unfaulted | |.............|-----------| next 3. Both adjacent VMAs unfaulted: copied -----| v |-----------|.............|-----------| | unfaulted |(faulted VMA)| unfaulted | |-----------|.............|-----------| prev next This series fixes each of these cases, and introduces self tests to assert that the issues are corrected. I also test a further case which was already handled, to assert that my changes continues to correctly handle it: 4. prev unfaulted, next faulted: copied -----| v |-----------|.............|-----------| | unfaulted |(faulted VMA)| faulted | |-----------|.............|-----------| prev next This bug was discovered via a syzbot report, linked to in the first patch in the series, I confirmed that this series fixes the bug. I also discovered that we are failing to check that the faulted VMA was not forked when merging a copied VMA in cases 1-3 above, an issue this series also addresses. I also added self tests to assert that this is resolved (and confirmed that the tests failed prior to this). I also cleaned up vma_expand() as part of this work, renamed vma_had_uncowed_parents() to vma_is_fork_child() as the previous name was unduly confusing, and simplified the comments around this function. This patch (of 4): Commit 879bca0a2c4f ("mm/vma: fix incorrectly disallowed anonymous VMA merges") introduced the ability to merge previously unavailable VMA merge scenarios. The key piece of logic introduced was the ability to merge a faulted VMA immediately next to an unfaulted VMA, which relies upon dup_anon_vma() to correctly handle anon_vma state. In the case of the merge of an existing VMA (that is changing properties of a VMA and then merging if those properties are shared by adjacent VMAs), dup_anon_vma() is invoked correctly. However in the case of the merge of a new VMA, a corner case peculiar to mremap() was missed. The issue is that vma_expand() only performs dup_anon_vma() if the target (the VMA that will ultimately become the merged VMA): is not the next VMA, i.e. the one that appears after the range in which the new VMA is to be established. A key insight here is that in all other cases other than mremap(), a new VMA merge either expands an existing VMA, meaning that the target VMA will be that VMA, or would have anon_vma be NULL. Specifically: * __mmap_region() - no anon_vma in place, initial mapping. * do_brk_flags() - expanding an existing VMA. * vma_merge_extend() - expanding an existing VMA. * relocate_vma_down() - no anon_vma in place, initial mapping. In addition, we are in the unique situation of needing to duplicate anon_vma state from a VMA that is neither the previous or next VMA being merged with. dup_anon_vma() deals exclusively with the target=unfaulted, src=faulted case. This leaves four possibilities, in each case where the copied VMA is faulted: 1. Previous VMA unfaulted: copied -----| ---truncated--- | ||||
| CVE-2026-23098 | 1 Linux | 1 Linux Kernel | 2026-04-16 | 8.8 High |
| In the Linux kernel, the following vulnerability has been resolved: netrom: fix double-free in nr_route_frame() In nr_route_frame(), old_skb is immediately freed without checking if nr_neigh->ax25 pointer is NULL. Therefore, if nr_neigh->ax25 is NULL, the caller function will free old_skb again, causing a double-free bug. Therefore, to prevent this, we need to modify it to check whether nr_neigh->ax25 is NULL before freeing old_skb. | ||||
| CVE-2026-1909 | 1 Wordpress | 1 Wordpress | 2026-04-16 | 6.4 Medium |
| The WaveSurfer-WP plugin for WordPress is vulnerable to Stored Cross-Site Scripting via the plugin's audio shortcode in all versions up to, and including, 2.8.3 due to insufficient input sanitization and output escaping on the 'src' attribute. 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. | ||||
| CVE-2026-0996 | 2 Techjewel, Wordpress | 2 Fluent Forms – Customizable Contact Forms, Survey, Quiz, & Conversational Form Builder, Wordpress | 2026-04-16 | 6.4 Medium |
| The Fluent Forms plugin for WordPress is vulnerable to Stored Cross-Site Scripting via the AI Form Builder module in all versions up to, and including, 6.1.14 due to a combination of missing authorization checks, a leaked nonce, and insufficient input sanitization. The vulnerability allows Subscriber-level users to trigger AI form generation via a protected endpoint. When prompted, AI services will typically return bare JavaScript code (without <script> tags), which bypasses the plugin's sanitization. This stored JavaScript executes whenever anyone views the generated form, making it possible for authenticated attackers with Subscriber-level access and above to inject arbitrary web scripts that will execute in the context of any user accessing the form. | ||||
| CVE-2026-0653 | 1 Tp-link | 3 Tapo C260, Tapo C260 Firmware, Tapo C260 V1 | 2026-04-16 | 6.5 Medium |
| On TP-Link Tapo C260 v1 and D235 v1, a guest‑level authenticated user can bypass intended access restrictions by sending crafted requests to a synchronization endpoint. This allows modification of protected device settings despite limited privileges. An attacker may change sensitive configuration parameters without authorization, resulting in unauthorized device state manipulation but not full code execution. | ||||
| CVE-2026-21519 | 1 Microsoft | 25 Windows 10 1607, Windows 10 1809, Windows 10 21h2 and 22 more | 2026-04-16 | 7.8 High |
| Access of resource using incompatible type ('type confusion') in Desktop Window Manager allows an authorized attacker to elevate privileges locally. | ||||
| CVE-2026-20611 | 1 Apple | 7 Ios And Ipados, Ipados, Iphone Os and 4 more | 2026-04-16 | 7.8 High |
| An out-of-bounds access issue was addressed with improved bounds checking. This issue is fixed in iOS 18.7.5 and iPadOS 18.7.5, iOS 26.3 and iPadOS 26.3, macOS Sequoia 15.7.4, macOS Sonoma 14.8.4, macOS Tahoe 26.3, tvOS 26.3, visionOS 26.3, watchOS 26.3. Processing a maliciously crafted media file may lead to unexpected app termination or corrupt process memory. | ||||
| CVE-2026-20661 | 1 Apple | 3 Ios And Ipados, Ipados, Iphone Os | 2026-04-16 | 4.6 Medium |
| An authorization issue was addressed with improved state management. This issue is fixed in iOS 18.7.5 and iPadOS 18.7.5, iOS 26.3 and iPadOS 26.3. An attacker with physical access to a locked device may be able to view sensitive user information. | ||||
| CVE-2026-20617 | 1 Apple | 7 Ios And Ipados, Ipados, Iphone Os and 4 more | 2026-04-16 | 7.0 High |
| A race condition was addressed with improved state handling. This issue is fixed in iOS 26.3 and iPadOS 26.3, macOS Sonoma 14.8.4, macOS Tahoe 26.3, tvOS 26.3, visionOS 26.3, watchOS 26.3. An app may be able to gain root privileges. | ||||
| CVE-2026-20601 | 1 Apple | 1 Macos | 2026-04-16 | 3.3 Low |
| A permissions issue was addressed with additional restrictions. This issue is fixed in macOS Tahoe 26.3. An app may be able to monitor keystrokes without user permission. | ||||
| CVE-2026-20602 | 1 Apple | 1 Macos | 2026-04-16 | 5.5 Medium |
| The issue was addressed with improved handling of caches. This issue is fixed in macOS Sequoia 15.7.4, macOS Sonoma 14.8.4, macOS Tahoe 26.3. An app may be able to cause a denial-of-service. | ||||