Export limit exceeded: 17643 CVEs match your query. Please refine your search to export 10,000 CVEs or fewer.
Export limit exceeded: 17643 CVEs match your query. Please refine your search to export 10,000 CVEs or fewer.
Export limit exceeded: 346262 CVEs match your query. Please refine your search to export 10,000 CVEs or fewer.
Search
Search Results (346262 CVEs found)
| CVE | Vendors | Products | Updated | CVSS v3.1 |
|---|---|---|---|---|
| CVE-2024-29076 | 2026-04-15 | 5.5 Medium | ||
| Uncaught exception for some Intel(R) CST software before version 8.7.10803 may allow an authenticated user to potentially enable denial of service via local access. | ||||
| CVE-2025-10147 | 2 Podlove, Wordpress | 2 Podlove Podcast Publisher, Wordpress | 2026-04-15 | 9.8 Critical |
| The Podlove Podcast Publisher plugin for WordPress is vulnerable to arbitrary file uploads due to missing file type validation in the 'move_as_original_file' function in all versions up to, and including, 4.2.6. This makes it possible for unauthenticated attackers to upload arbitrary files on the affected site's server which may make remote code execution possible. | ||||
| CVE-2024-32079 | 1 Wordpress | 1 Wordpress | 2026-04-15 | 6.5 Medium |
| Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting') vulnerability in Michael Dempfle Advanced iFrame allows Stored XSS.This issue affects Advanced iFrame: from n/a through 2024.2. | ||||
| CVE-2024-12854 | 2026-04-15 | 8.8 High | ||
| The Garden Gnome Package plugin for WordPress is vulnerable to arbitrary file uploads due to missing file type validation in the functionality that automatically extracts 'ggpkg' files that have been uploaded in all versions up to, and including, 2.3.0. This makes it possible for authenticated attackers, with Author-level access and above, to upload arbitrary files on the affected site's server which may make remote code execution possible. | ||||
| CVE-2024-4232 | 2026-04-15 | 4.1 Medium | ||
| This vulnerability exists in Digisol Router (DG-GR1321: Hardware version 3.7L; Firmware version : v3.2.02) due to lack of encryption or hashing in storing of passwords within the router's firmware/ database. An attacker with physical access could exploit this by extracting the firmware and reverse engineer the binary data to access the plaintext passwords on the vulnerable system. Successful exploitation of this vulnerability could allow the attacker to gain unauthorized access to the targeted system. | ||||
| CVE-2025-58400 | 2 Microsoft, Ratocsystems | 2 Windows, Raid Monitoring Manager | 2026-04-15 | N/A |
| RATOC RAID Monitoring Manager for Windows provided by RATOC Systems, Inc. registers a Windows service with an unquoted file path. A user with the write permission on the root directory of the system drive may execute arbitrary code with SYSTEM privilege. | ||||
| CVE-2024-3491 | 2 Magazine3, Wordpress | 2 Schema & Structured Data For Wp & Amp, Wordpress | 2026-04-15 | 6.4 Medium |
| The Schema & Structured Data for WP & AMP plugin for WordPress is vulnerable to Stored Cross-Site Scripting via the plugin's "How To" and "FAQ" Blocks in all versions up to, and including, 1.29 due to insufficient input sanitization and output escaping on user supplied attributes. 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-2025-40348 | 1 Linux | 1 Linux Kernel | 2026-04-15 | 7.0 High |
| In the Linux kernel, the following vulnerability has been resolved: slab: Avoid race on slab->obj_exts in alloc_slab_obj_exts If two competing threads enter alloc_slab_obj_exts() and one of them fails to allocate the object extension vector, it might override the valid slab->obj_exts allocated by the other thread with OBJEXTS_ALLOC_FAIL. This will cause the thread that lost this race and expects a valid pointer to dereference a NULL pointer later on. Update slab->obj_exts atomically using cmpxchg() to avoid slab->obj_exts overrides by racing threads. Thanks for Vlastimil and Suren's help with debugging. | ||||
| CVE-2010-20120 | 1 Maplesoft | 2 Maple, Maple T.a. | 2026-04-15 | N/A |
| Maple versions up to and including 13's Maplet framework allows embedded commands to be executed automatically when a .maplet file is opened. This behavior bypasses standard security restrictions that normally prevent code execution in regular Maple worksheets. The vulnerability enables attackers to craft malicious .maplet files that execute arbitrary code without user interaction. | ||||
| CVE-2025-40015 | 1 Linux | 1 Linux Kernel | 2026-04-15 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: media: stm32-csi: Fix dereference before NULL check In 'stm32_csi_start', 'csidev->s_subdev' is dereferenced directly while assigning a value to the 'src_pad'. However the same value is being checked against NULL at a later point of time indicating that there are chances that the value can be NULL. Move the dereference after the NULL check. | ||||
| CVE-2025-40350 | 1 Linux | 1 Linux Kernel | 2026-04-15 | 7.0 High |
| In the Linux kernel, the following vulnerability has been resolved: net/mlx5e: RX, Fix generating skb from non-linear xdp_buff for striding RQ XDP programs can change the layout of an xdp_buff through bpf_xdp_adjust_tail() and bpf_xdp_adjust_head(). Therefore, the driver cannot assume the size of the linear data area nor fragments. Fix the bug in mlx5 by generating skb according to xdp_buff after XDP programs run. Currently, when handling multi-buf XDP, the mlx5 driver assumes the layout of an xdp_buff to be unchanged. That is, the linear data area continues to be empty and fragments remain the same. This may cause the driver to generate erroneous skb or triggering a kernel warning. When an XDP program added linear data through bpf_xdp_adjust_head(), the linear data will be ignored as mlx5e_build_linear_skb() builds an skb without linear data and then pull data from fragments to fill the linear data area. When an XDP program has shrunk the non-linear data through bpf_xdp_adjust_tail(), the delta passed to __pskb_pull_tail() may exceed the actual nonlinear data size and trigger the BUG_ON in it. To fix the issue, first record the original number of fragments. If the number of fragments changes after the XDP program runs, rewind the end fragment pointer by the difference and recalculate the truesize. Then, build the skb with the linear data area matching the xdp_buff. Finally, only pull data in if there is non-linear data and fill the linear part up to 256 bytes. | ||||
| CVE-2025-40352 | 1 Linux | 1 Linux Kernel | 2026-04-15 | N/A |
| In the Linux kernel, the following vulnerability has been resolved: platform/mellanox: mlxbf-pmc: add sysfs_attr_init() to count_clock init The lock-related debug logic (CONFIG_LOCK_STAT) in the kernel is noting the following warning when the BlueField-3 SOC is booted: BUG: key ffff00008a3402a8 has not been registered! ------------[ cut here ]------------ DEBUG_LOCKS_WARN_ON(1) WARNING: CPU: 4 PID: 592 at kernel/locking/lockdep.c:4801 lockdep_init_map_type+0x1d4/0x2a0 <snip> Call trace: lockdep_init_map_type+0x1d4/0x2a0 __kernfs_create_file+0x84/0x140 sysfs_add_file_mode_ns+0xcc/0x1cc internal_create_group+0x110/0x3d4 internal_create_groups.part.0+0x54/0xcc sysfs_create_groups+0x24/0x40 device_add+0x6e8/0x93c device_register+0x28/0x40 __hwmon_device_register+0x4b0/0x8a0 devm_hwmon_device_register_with_groups+0x7c/0xe0 mlxbf_pmc_probe+0x1e8/0x3e0 [mlxbf_pmc] platform_probe+0x70/0x110 The mlxbf_pmc driver must call sysfs_attr_init() during the initialization of the "count_clock" data structure to avoid this warning. | ||||
| CVE-2025-40353 | 1 Linux | 1 Linux Kernel | 2026-04-15 | 7.0 High |
| In the Linux kernel, the following vulnerability has been resolved: arm64: mte: Do not warn if the page is already tagged in copy_highpage() The arm64 copy_highpage() assumes that the destination page is newly allocated and not MTE-tagged (PG_mte_tagged unset) and warns accordingly. However, following commit 060913999d7a ("mm: migrate: support poisoned recover from migrate folio"), folio_mc_copy() is called before __folio_migrate_mapping(). If the latter fails (-EAGAIN), the copy will be done again to the same destination page. Since copy_highpage() already set the PG_mte_tagged flag, this second copy will warn. Replace the WARN_ON_ONCE(page already tagged) in the arm64 copy_highpage() with a comment. | ||||
| CVE-2025-40355 | 1 Linux | 1 Linux Kernel | 2026-04-15 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: sysfs: check visibility before changing group attribute ownership Since commit 0c17270f9b92 ("net: sysfs: Implement is_visible for phys_(port_id, port_name, switch_id)"), __dev_change_net_namespace() can hit WARN_ON() when trying to change owner of a file that isn't visible. See the trace below: WARNING: CPU: 6 PID: 2938 at net/core/dev.c:12410 __dev_change_net_namespace+0xb89/0xc30 CPU: 6 UID: 0 PID: 2938 Comm: incusd Not tainted 6.17.1-1-mainline #1 PREEMPT(full) 4b783b4a638669fb644857f484487d17cb45ed1f Hardware name: Framework Laptop 13 (AMD Ryzen 7040Series)/FRANMDCP07, BIOS 03.07 02/19/2025 RIP: 0010:__dev_change_net_namespace+0xb89/0xc30 [...] Call Trace: <TASK> ? if6_seq_show+0x30/0x50 do_setlink.isra.0+0xc7/0x1270 ? __nla_validate_parse+0x5c/0xcc0 ? security_capable+0x94/0x1a0 rtnl_newlink+0x858/0xc20 ? update_curr+0x8e/0x1c0 ? update_entity_lag+0x71/0x80 ? sched_balance_newidle+0x358/0x450 ? psi_task_switch+0x113/0x2a0 ? __pfx_rtnl_newlink+0x10/0x10 rtnetlink_rcv_msg+0x346/0x3e0 ? sched_clock+0x10/0x30 ? __pfx_rtnetlink_rcv_msg+0x10/0x10 netlink_rcv_skb+0x59/0x110 netlink_unicast+0x285/0x3c0 ? __alloc_skb+0xdb/0x1a0 netlink_sendmsg+0x20d/0x430 ____sys_sendmsg+0x39f/0x3d0 ? import_iovec+0x2f/0x40 ___sys_sendmsg+0x99/0xe0 __sys_sendmsg+0x8a/0xf0 do_syscall_64+0x81/0x970 ? __sys_bind+0xe3/0x110 ? syscall_exit_work+0x143/0x1b0 ? do_syscall_64+0x244/0x970 ? sock_alloc_file+0x63/0xc0 ? syscall_exit_work+0x143/0x1b0 ? do_syscall_64+0x244/0x970 ? alloc_fd+0x12e/0x190 ? put_unused_fd+0x2a/0x70 ? do_sys_openat2+0xa2/0xe0 ? syscall_exit_work+0x143/0x1b0 ? do_syscall_64+0x244/0x970 ? exc_page_fault+0x7e/0x1a0 entry_SYSCALL_64_after_hwframe+0x76/0x7e [...] </TASK> Fix this by checking is_visible() before trying to touch the attribute. | ||||
| CVE-2025-40358 | 1 Linux | 1 Linux Kernel | 2026-04-15 | N/A |
| In the Linux kernel, the following vulnerability has been resolved: riscv: stacktrace: Disable KASAN checks for non-current tasks Unwinding the stack of a task other than current, KASAN would report "BUG: KASAN: out-of-bounds in walk_stackframe+0x41c/0x460" There is a same issue on x86 and has been resolved by the commit 84936118bdf3 ("x86/unwind: Disable KASAN checks for non-current tasks") The solution could be applied to RISC-V too. This patch also can solve the issue: https://seclists.org/oss-sec/2025/q4/23 [pjw@kernel.org: clean up checkpatch issues] | ||||
| CVE-2025-40359 | 1 Linux | 1 Linux Kernel | 2026-04-15 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: perf/x86/intel: Fix KASAN global-out-of-bounds warning When running "perf mem record" command on CWF, the below KASAN global-out-of-bounds warning is seen. ================================================================== BUG: KASAN: global-out-of-bounds in cmt_latency_data+0x176/0x1b0 Read of size 4 at addr ffffffffb721d000 by task dtlb/9850 Call Trace: kasan_report+0xb8/0xf0 cmt_latency_data+0x176/0x1b0 setup_arch_pebs_sample_data+0xf49/0x2560 intel_pmu_drain_arch_pebs+0x577/0xb00 handle_pmi_common+0x6c4/0xc80 The issue is caused by below code in __grt_latency_data(). The code tries to access x86_hybrid_pmu structure which doesn't exist on non-hybrid platform like CWF. WARN_ON_ONCE(hybrid_pmu(event->pmu)->pmu_type == hybrid_big) So add is_hybrid() check before calling this WARN_ON_ONCE to fix the global-out-of-bounds access issue. | ||||
| CVE-2025-40360 | 1 Linux | 1 Linux Kernel | 2026-04-15 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: drm/sysfb: Do not dereference NULL pointer in plane reset The plane state in __drm_gem_reset_shadow_plane() can be NULL. Do not deref that pointer, but forward NULL to the other plane-reset helpers. Clears plane->state to NULL. v2: - fix typo in commit description (Javier) | ||||
| CVE-2025-40362 | 1 Linux | 1 Linux Kernel | 2026-04-15 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: ceph: fix multifs mds auth caps issue The mds auth caps check should also validate the fsname along with the associated caps. Not doing so would result in applying the mds auth caps of one fs on to the other fs in a multifs ceph cluster. The bug causes multiple issues w.r.t user authentication, following is one such example. Steps to Reproduce (on vstart cluster): 1. Create two file systems in a cluster, say 'fsname1' and 'fsname2' 2. Authorize read only permission to the user 'client.usr' on fs 'fsname1' $ceph fs authorize fsname1 client.usr / r 3. Authorize read and write permission to the same user 'client.usr' on fs 'fsname2' $ceph fs authorize fsname2 client.usr / rw 4. Update the keyring $ceph auth get client.usr >> ./keyring With above permssions for the user 'client.usr', following is the expectation. a. The 'client.usr' should be able to only read the contents and not allowed to create or delete files on file system 'fsname1'. b. The 'client.usr' should be able to read/write on file system 'fsname2'. But, with this bug, the 'client.usr' is allowed to read/write on file system 'fsname1'. See below. 5. Mount the file system 'fsname1' with the user 'client.usr' $sudo bin/mount.ceph usr@.fsname1=/ /kmnt_fsname1_usr/ 6. Try creating a file on file system 'fsname1' with user 'client.usr'. This should fail but passes with this bug. $touch /kmnt_fsname1_usr/file1 7. Mount the file system 'fsname1' with the user 'client.admin' and create a file. $sudo bin/mount.ceph admin@.fsname1=/ /kmnt_fsname1_admin $echo "data" > /kmnt_fsname1_admin/admin_file1 8. Try removing an existing file on file system 'fsname1' with the user 'client.usr'. This shoudn't succeed but succeeds with the bug. $rm -f /kmnt_fsname1_usr/admin_file1 For more information, please take a look at the corresponding mds/fuse patch and tests added by looking into the tracker mentioned below. v2: Fix a possible null dereference in doutc v3: Don't store fsname from mdsmap, validate against ceph_mount_options's fsname and use it v4: Code refactor, better warning message and fix possible compiler warning [ Slava.Dubeyko: "fsname check failed" -> "fsname mismatch" ] | ||||
| CVE-2025-40570 | 1 Siemens | 1 Siprotec 5 | 2026-04-15 | 2.4 Low |
| A vulnerability has been identified in SIPROTEC 5 6MD84 (CP300) (All versions < V10.0), SIPROTEC 5 6MD85 (CP300) (All versions >= V7.80 < V10.0), SIPROTEC 5 6MD86 (CP300) (All versions >= V7.80 < V10.0), SIPROTEC 5 6MD89 (CP300) (All versions >= V7.80 < V10.0), SIPROTEC 5 6MU85 (CP300) (All versions >= V7.80 < V10.0), SIPROTEC 5 7KE85 (CP300) (All versions >= V7.80 < V10.0), SIPROTEC 5 7SA82 (CP150) (All versions < V10.0), SIPROTEC 5 7SA86 (CP300) (All versions >= V7.80 < V10.0), SIPROTEC 5 7SA87 (CP300) (All versions >= V7.80 < V10.0), SIPROTEC 5 7SD82 (CP150) (All versions < V10.0), SIPROTEC 5 7SD86 (CP300) (All versions >= V7.80 < V10.0), SIPROTEC 5 7SD87 (CP300) (All versions >= V7.80 < V10.0), SIPROTEC 5 7SJ81 (CP150) (All versions < V10.0), SIPROTEC 5 7SJ82 (CP150) (All versions < V10.0), SIPROTEC 5 7SJ85 (CP300) (All versions >= V7.80 < V10.0), SIPROTEC 5 7SJ86 (CP300) (All versions >= V7.80 < V10.0), SIPROTEC 5 7SK82 (CP150) (All versions < V10.0), SIPROTEC 5 7SK85 (CP300) (All versions >= V7.80 < V10.0), SIPROTEC 5 7SL82 (CP150) (All versions < V10.0), SIPROTEC 5 7SL86 (CP300) (All versions >= V7.80 < V10.0), SIPROTEC 5 7SL87 (CP300) (All versions >= V7.80 < V10.0), SIPROTEC 5 7SS85 (CP300) (All versions >= V7.80 < V10.0), SIPROTEC 5 7ST85 (CP300) (All versions < V10.0), SIPROTEC 5 7ST86 (CP300) (All versions < V10.0), SIPROTEC 5 7SX82 (CP150) (All versions < V10.0), SIPROTEC 5 7SX85 (CP300) (All versions < V10.0), SIPROTEC 5 7SY82 (CP150) (All versions < V10.0), SIPROTEC 5 7UM85 (CP300) (All versions >= V7.80 < V10.0), SIPROTEC 5 7UT82 (CP150) (All versions < V10.0), SIPROTEC 5 7UT85 (CP300) (All versions >= V7.80 < V10.0), SIPROTEC 5 7UT86 (CP300) (All versions >= V7.80 < V10.0), SIPROTEC 5 7UT87 (CP300) (All versions >= V7.80 < V10.0), SIPROTEC 5 7VE85 (CP300) (All versions >= V7.80 < V10.0), SIPROTEC 5 7VK87 (CP300) (All versions >= V7.80 < V10.0), SIPROTEC 5 7VU85 (CP300) (All versions < V10.0), SIPROTEC 5 Compact 7SX800 (CP050) (All versions < V10.0). Affected devices do not properly limit the bandwidth for incoming network packets over their local USB port. This could allow an attacker with physical access to send specially crafted packets with high bandwidth to the affected devices thus forcing them to exhaust their memory and stop responding to any network traffic via the local USB port. Affected devices reset themselves automatically after a successful attack. The protection function is not affected of this vulnerability. | ||||
| CVE-2025-40584 | 1 Siemens | 3 Simotion Scout, Simotion Scout Tia, Sinamics Starter | 2026-04-15 | 5.5 Medium |
| A vulnerability has been identified in SIMOTION SCOUT TIA V5.4 (All versions), SIMOTION SCOUT TIA V5.5 (All versions), SIMOTION SCOUT TIA V5.6 (All versions < V5.6 SP1 HF7), SIMOTION SCOUT TIA V5.7 (All versions < V5.7 SP1 HF1), SIMOTION SCOUT V5.4 (All versions), SIMOTION SCOUT V5.5 (All versions), SIMOTION SCOUT V5.6 (All versions < V5.6 SP1 HF7), SIMOTION SCOUT V5.7 (All versions < V5.7 SP1 HF1), SINAMICS STARTER V5.5 (All versions), SINAMICS STARTER V5.6 (All versions), SINAMICS STARTER V5.7 (All versions < V5.7 HF2). The affected application contains a XML External Entity Injection (XXE) vulnerability while parsing specially crafted XML files. This could allow an attacker to read arbitrary files in the system. | ||||