Export limit exceeded: 347708 CVEs match your query. Please refine your search to export 10,000 CVEs or fewer.
Search
Search Results (347708 CVEs found)
| CVE | Vendors | Products | Updated | CVSS v3.1 |
|---|---|---|---|---|
| CVE-2025-52873 | 1 Cognex | 2 In-sight Camera Firmware, In-sight Explorer | 2026-04-15 | 8.1 High |
| Cognex In-Sight Explorer and In-Sight Camera Firmware expose a telnet-based service on port 23 to allow management operations such as firmware upgrades and device reboots, which require authentication. A user with protected privileges can successfully invoke the SetSystemConfig functionality to modify relevant device properties (such as network settings), contradicting the security model proposed in the user manual. | ||||
| CVE-2025-5288 | 2026-04-15 | 9.8 Critical | ||
| The REST API | Custom API Generator For Cross Platform And Import Export In WP plugin for WordPress is vulnerable to Privilege Escalation due to a missing capability check on the process_handler() function in versions 1.0.0 to 2.0.3. This makes it possible for unauthenticated attackers to POST an arbitrary import_api URL, import specially crafted JSON, and thereby create a new user with full Administrator privileges. | ||||
| CVE-2020-36921 | 2026-04-15 | 7.5 High | ||
| RED-V Super Digital Signage System 5.1.1 contains an information disclosure vulnerability that allows unauthenticated attackers to access sensitive webserver log files. Attackers can visit multiple endpoints to retrieve system resources and debug log information without authentication. | ||||
| CVE-2025-52884 | 1 Risc Zero Project | 1 Risc Zero | 2026-04-15 | N/A |
| RISC Zero is a zero-knowledge verifiable general computing platform, with Ethereum integration. The risc0-ethereum repository contains Solidity verifier contracts, Steel EVM view call library, and supporting code. Prior to versions 2.1.1 and 2.2.0, the `Steel.validateCommitment` Solidity library function will return `true` for a crafted commitment with a digest value of zero. This violates the semantics of `validateCommitment`, as this does not commitment to a block that is in the current chain. Because the digest is zero, it does not correspond to any block and there exist no known openings. As a result, this commitment will never be produced by a correct zkVM guest using Steel and leveraging this bug to compromise the soundness of a program using Steel would require a separate bug or misuse of the Steel library, which is expected to be used to validate the root of state opening proofs. A fix has been released as part of `risc0-ethereum` 2.1.1 and 2.2.0. Users for the `Steel` Solidity library versions 2.1.0 or earlier should ensure they are using `Steel.validateCommitment` in tandem with zkVM proof verification of a Steel program, as shown in the ERC-20 counter example, and documentation. This is the correct usage of Steel, and users following this pattern are not at risk, and do not need to take action. Users not verifying a zkVM proof of a Steel program should update their application to do so, as this is incorrect usage of Steel. | ||||
| CVE-2025-13805 | 1 Nutzam | 1 Nutzboot | 2026-04-15 | 3.7 Low |
| A weakness has been identified in nutzam NutzBoot up to 2.6.0-SNAPSHOT. This affects the function getInputStream of the file nutzcloud/nutzcloud-literpc/src/main/java/org/nutz/boot/starter/literpc/impl/endpoint/http/HttpServletRpcEndpoint.java of the component LiteRpc-Serializer. Executing a manipulation can lead to deserialization. The attack may be launched remotely. This attack is characterized by high complexity. The exploitability is reported as difficult. The exploit has been made available to the public and could be used for attacks. | ||||
| CVE-2025-40241 | 1 Linux | 1 Linux Kernel | 2026-04-15 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: erofs: fix crafted invalid cases for encoded extents Robert recently reported two corrupted images that can cause system crashes, which are related to the new encoded extents introduced in Linux 6.15: - The first one [1] has plen != 0 (e.g. plen == 0x2000000) but (plen & Z_EROFS_EXTENT_PLEN_MASK) == 0. It is used to represent special extents such as sparse extents (!EROFS_MAP_MAPPED), but previously only plen == 0 was handled; - The second one [2] has pa 0xffffffffffdcffed and plen 0xb4000, then "cur [0xfffffffffffff000] += bvec.bv_len [0x1000]" in "} while ((cur += bvec.bv_len) < end);" wraps around, causing an out-of-bound access of pcl->compressed_bvecs[] in z_erofs_submit_queue(). EROFS only supports 48-bit physical block addresses (up to 1EiB for 4k blocks), so add a sanity check to enforce this. | ||||
| CVE-2025-27148 | 2026-04-15 | 8.8 High | ||
| Gradle is a build automation tool, and its native-platform tool provides Java bindings for native APIs. On Unix-like systems, the system temporary directory can be created with open permissions that allow multiple users to create and delete files within it. This library initialization could be vulnerable to a local privilege escalation from an attacker quickly deleting and recreating files in the system temporary directory. Gradle builds that rely on versions of net.rubygrapefruit:native-platform prior to 0.22-milestone-28 could be vulnerable to a local privilege escalation from an attacker quickly deleting and recreating files in the system temporary directory. In net.rubygrapefruit:native-platform prior to version 0.22-milestone-28, if the `Native.get(Class<>)` method was called, without calling `Native.init(File)` first, with a non-`null` argument used as working file path, then the library would initialize itself using the system temporary directory and NativeLibraryLocator.java lines 68 through 78. Version 0.22-milestone-28 has been released with changes that fix the problem. Initialization is now mandatory and no longer uses the system temporary directory, unless such a path is passed for initialization. The only workaround for affected versions is to make sure to do a proper initialization, using a location that is safe. Gradle 8.12, only that exact version, had codepaths where the initialization of the underlying native integration library took a default path, relying on copying the binaries to the system temporary directory. Any execution of Gradle exposed this exploit. Users of Windows or modern versions of macOS are not vulnerable, nor are users of a Unix-like operating system with the "sticky" bit set or `noexec` on their system temporary directory vulnerable. This problem was fixed in Gradle 8.12.1. Gradle 8.13 release also upgrades to a version of the native library that no longer has that bug. Some workarounds are available. On Unix-like operating systems, ensure that the "sticky" bit is set. This only allows the original user (or root) to delete a file. Mounting `/tmp` as `noexec` will prevent Gradle 8.12 from starting. Those who are are unable to change the permissions of the system temporary directory can move the Java temporary directory by setting the System Property java.io.tmpdir. The new path needs to limit permissions to the build user only. | ||||
| CVE-2025-40243 | 1 Linux | 1 Linux Kernel | 2026-04-15 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: hfs: fix KMSAN uninit-value issue in hfs_find_set_zero_bits() The syzbot reported issue in hfs_find_set_zero_bits(): ===================================================== BUG: KMSAN: uninit-value in hfs_find_set_zero_bits+0x74d/0xb60 fs/hfs/bitmap.c:45 hfs_find_set_zero_bits+0x74d/0xb60 fs/hfs/bitmap.c:45 hfs_vbm_search_free+0x13c/0x5b0 fs/hfs/bitmap.c:151 hfs_extend_file+0x6a5/0x1b00 fs/hfs/extent.c:408 hfs_get_block+0x435/0x1150 fs/hfs/extent.c:353 __block_write_begin_int+0xa76/0x3030 fs/buffer.c:2151 block_write_begin fs/buffer.c:2262 [inline] cont_write_begin+0x10e1/0x1bc0 fs/buffer.c:2601 hfs_write_begin+0x85/0x130 fs/hfs/inode.c:52 cont_expand_zero fs/buffer.c:2528 [inline] cont_write_begin+0x35a/0x1bc0 fs/buffer.c:2591 hfs_write_begin+0x85/0x130 fs/hfs/inode.c:52 hfs_file_truncate+0x1d6/0xe60 fs/hfs/extent.c:494 hfs_inode_setattr+0x964/0xaa0 fs/hfs/inode.c:654 notify_change+0x1993/0x1aa0 fs/attr.c:552 do_truncate+0x28f/0x310 fs/open.c:68 do_ftruncate+0x698/0x730 fs/open.c:195 do_sys_ftruncate fs/open.c:210 [inline] __do_sys_ftruncate fs/open.c:215 [inline] __se_sys_ftruncate fs/open.c:213 [inline] __x64_sys_ftruncate+0x11b/0x250 fs/open.c:213 x64_sys_call+0xfe3/0x3db0 arch/x86/include/generated/asm/syscalls_64.h:78 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xd9/0x210 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7f Uninit was created at: slab_post_alloc_hook mm/slub.c:4154 [inline] slab_alloc_node mm/slub.c:4197 [inline] __kmalloc_cache_noprof+0x7f7/0xed0 mm/slub.c:4354 kmalloc_noprof include/linux/slab.h:905 [inline] hfs_mdb_get+0x1cc8/0x2a90 fs/hfs/mdb.c:175 hfs_fill_super+0x3d0/0xb80 fs/hfs/super.c:337 get_tree_bdev_flags+0x6e3/0x920 fs/super.c:1681 get_tree_bdev+0x38/0x50 fs/super.c:1704 hfs_get_tree+0x35/0x40 fs/hfs/super.c:388 vfs_get_tree+0xb0/0x5c0 fs/super.c:1804 do_new_mount+0x738/0x1610 fs/namespace.c:3902 path_mount+0x6db/0x1e90 fs/namespace.c:4226 do_mount fs/namespace.c:4239 [inline] __do_sys_mount fs/namespace.c:4450 [inline] __se_sys_mount+0x6eb/0x7d0 fs/namespace.c:4427 __x64_sys_mount+0xe4/0x150 fs/namespace.c:4427 x64_sys_call+0xfa7/0x3db0 arch/x86/include/generated/asm/syscalls_64.h:166 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xd9/0x210 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7f CPU: 1 UID: 0 PID: 12609 Comm: syz.1.2692 Not tainted 6.16.0-syzkaller #0 PREEMPT(none) Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 07/12/2025 ===================================================== The HFS_SB(sb)->bitmap buffer is allocated in hfs_mdb_get(): HFS_SB(sb)->bitmap = kmalloc(8192, GFP_KERNEL); Finally, it can trigger the reported issue because kmalloc() doesn't clear the allocated memory. If allocated memory contains only zeros, then everything will work pretty fine. But if the allocated memory contains the "garbage", then it can affect the bitmap operations and it triggers the reported issue. This patch simply exchanges the kmalloc() on kzalloc() with the goal to guarantee the correctness of bitmap operations. Because, newly created allocation bitmap should have all available blocks free. Potentially, initialization bitmap's read operation could not fill the whole allocated memory and "garbage" in the not initialized memory will be the reason of volume coruptions and file system driver bugs. | ||||
| CVE-2025-0029 | 1 Amd | 2 Epyc 9005 Series Processors, Epyc Embedded 9005 Series Processors | 2026-04-15 | N/A |
| Improper handling of error condition during host-induced faults can allow a local high-privileged attack to selectively drop guest DMA writes, potentially resulting in a loss of SEV-SNP guest memory integrity | ||||
| CVE-2025-24313 | 2 Intel, Kubernetes | 2 Device Plugins For Kubernetes, Kubernetes | 2026-04-15 | 4.4 Medium |
| Improper access control for some Device Plugins for Kubernetes software maintained by Intel before version 0.32.0 may allow a privileged user to potentially enable denial of service via local access. | ||||
| CVE-2025-40252 | 1 Linux | 1 Linux Kernel | 2026-04-15 | 7.0 High |
| In the Linux kernel, the following vulnerability has been resolved: net: qlogic/qede: fix potential out-of-bounds read in qede_tpa_cont() and qede_tpa_end() The loops in 'qede_tpa_cont()' and 'qede_tpa_end()', iterate over 'cqe->len_list[]' using only a zero-length terminator as the stopping condition. If the terminator was missing or malformed, the loop could run past the end of the fixed-size array. Add an explicit bound check using ARRAY_SIZE() in both loops to prevent a potential out-of-bounds access. Found by Linux Verification Center (linuxtesting.org) with SVACE. | ||||
| CVE-2025-40254 | 1 Linux | 1 Linux Kernel | 2026-04-15 | 7.0 High |
| In the Linux kernel, the following vulnerability has been resolved: net: openvswitch: remove never-working support for setting nsh fields The validation of the set(nsh(...)) action is completely wrong. It runs through the nsh_key_put_from_nlattr() function that is the same function that validates NSH keys for the flow match and the push_nsh() action. However, the set(nsh(...)) has a very different memory layout. Nested attributes in there are doubled in size in case of the masked set(). That makes proper validation impossible. There is also confusion in the code between the 'masked' flag, that says that the nested attributes are doubled in size containing both the value and the mask, and the 'is_mask' that says that the value we're parsing is the mask. This is causing kernel crash on trying to write into mask part of the match with SW_FLOW_KEY_PUT() during validation, while validate_nsh() doesn't allocate any memory for it: BUG: kernel NULL pointer dereference, address: 0000000000000018 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 1c2383067 P4D 1c2383067 PUD 20b703067 PMD 0 Oops: Oops: 0000 [#1] SMP NOPTI CPU: 8 UID: 0 Kdump: loaded Not tainted 6.17.0-rc4+ #107 PREEMPT(voluntary) RIP: 0010:nsh_key_put_from_nlattr+0x19d/0x610 [openvswitch] Call Trace: <TASK> validate_nsh+0x60/0x90 [openvswitch] validate_set.constprop.0+0x270/0x3c0 [openvswitch] __ovs_nla_copy_actions+0x477/0x860 [openvswitch] ovs_nla_copy_actions+0x8d/0x100 [openvswitch] ovs_packet_cmd_execute+0x1cc/0x310 [openvswitch] genl_family_rcv_msg_doit+0xdb/0x130 genl_family_rcv_msg+0x14b/0x220 genl_rcv_msg+0x47/0xa0 netlink_rcv_skb+0x53/0x100 genl_rcv+0x24/0x40 netlink_unicast+0x280/0x3b0 netlink_sendmsg+0x1f7/0x430 ____sys_sendmsg+0x36b/0x3a0 ___sys_sendmsg+0x87/0xd0 __sys_sendmsg+0x6d/0xd0 do_syscall_64+0x7b/0x2c0 entry_SYSCALL_64_after_hwframe+0x76/0x7e The third issue with this process is that while trying to convert the non-masked set into masked one, validate_set() copies and doubles the size of the OVS_KEY_ATTR_NSH as if it didn't have any nested attributes. It should be copying each nested attribute and doubling them in size independently. And the process must be properly reversed during the conversion back from masked to a non-masked variant during the flow dump. In the end, the only two outcomes of trying to use this action are either validation failure or a kernel crash. And if somehow someone manages to install a flow with such an action, it will most definitely not do what it is supposed to, since all the keys and the masks are mixed up. Fixing all the issues is a complex task as it requires re-writing most of the validation code. Given that and the fact that this functionality never worked since introduction, let's just remove it altogether. It's better to re-introduce it later with a proper implementation instead of trying to fix it in stable releases. | ||||
| CVE-2025-40257 | 1 Linux | 1 Linux Kernel | 2026-04-15 | 7.0 High |
| In the Linux kernel, the following vulnerability has been resolved: mptcp: fix a race in mptcp_pm_del_add_timer() mptcp_pm_del_add_timer() can call sk_stop_timer_sync(sk, &entry->add_timer) while another might have free entry already, as reported by syzbot. Add RCU protection to fix this issue. Also change confusing add_timer variable with stop_timer boolean. syzbot report: BUG: KASAN: slab-use-after-free in __timer_delete_sync+0x372/0x3f0 kernel/time/timer.c:1616 Read of size 4 at addr ffff8880311e4150 by task kworker/1:1/44 CPU: 1 UID: 0 PID: 44 Comm: kworker/1:1 Not tainted syzkaller #0 PREEMPT_{RT,(full)} Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/02/2025 Workqueue: events mptcp_worker Call Trace: <TASK> dump_stack_lvl+0x189/0x250 lib/dump_stack.c:120 print_address_description mm/kasan/report.c:378 [inline] print_report+0xca/0x240 mm/kasan/report.c:482 kasan_report+0x118/0x150 mm/kasan/report.c:595 __timer_delete_sync+0x372/0x3f0 kernel/time/timer.c:1616 sk_stop_timer_sync+0x1b/0x90 net/core/sock.c:3631 mptcp_pm_del_add_timer+0x283/0x310 net/mptcp/pm.c:362 mptcp_incoming_options+0x1357/0x1f60 net/mptcp/options.c:1174 tcp_data_queue+0xca/0x6450 net/ipv4/tcp_input.c:5361 tcp_rcv_established+0x1335/0x2670 net/ipv4/tcp_input.c:6441 tcp_v4_do_rcv+0x98b/0xbf0 net/ipv4/tcp_ipv4.c:1931 tcp_v4_rcv+0x252a/0x2dc0 net/ipv4/tcp_ipv4.c:2374 ip_protocol_deliver_rcu+0x221/0x440 net/ipv4/ip_input.c:205 ip_local_deliver_finish+0x3bb/0x6f0 net/ipv4/ip_input.c:239 NF_HOOK+0x30c/0x3a0 include/linux/netfilter.h:318 NF_HOOK+0x30c/0x3a0 include/linux/netfilter.h:318 __netif_receive_skb_one_core net/core/dev.c:6079 [inline] __netif_receive_skb+0x143/0x380 net/core/dev.c:6192 process_backlog+0x31e/0x900 net/core/dev.c:6544 __napi_poll+0xb6/0x540 net/core/dev.c:7594 napi_poll net/core/dev.c:7657 [inline] net_rx_action+0x5f7/0xda0 net/core/dev.c:7784 handle_softirqs+0x22f/0x710 kernel/softirq.c:622 __do_softirq kernel/softirq.c:656 [inline] __local_bh_enable_ip+0x1a0/0x2e0 kernel/softirq.c:302 mptcp_pm_send_ack net/mptcp/pm.c:210 [inline] mptcp_pm_addr_send_ack+0x41f/0x500 net/mptcp/pm.c:-1 mptcp_pm_worker+0x174/0x320 net/mptcp/pm.c:1002 mptcp_worker+0xd5/0x1170 net/mptcp/protocol.c:2762 process_one_work kernel/workqueue.c:3263 [inline] process_scheduled_works+0xae1/0x17b0 kernel/workqueue.c:3346 worker_thread+0x8a0/0xda0 kernel/workqueue.c:3427 kthread+0x711/0x8a0 kernel/kthread.c:463 ret_from_fork+0x4bc/0x870 arch/x86/kernel/process.c:158 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245 </TASK> Allocated by task 44: kasan_save_stack mm/kasan/common.c:56 [inline] kasan_save_track+0x3e/0x80 mm/kasan/common.c:77 poison_kmalloc_redzone mm/kasan/common.c:400 [inline] __kasan_kmalloc+0x93/0xb0 mm/kasan/common.c:417 kasan_kmalloc include/linux/kasan.h:262 [inline] __kmalloc_cache_noprof+0x1ef/0x6c0 mm/slub.c:5748 kmalloc_noprof include/linux/slab.h:957 [inline] mptcp_pm_alloc_anno_list+0x104/0x460 net/mptcp/pm.c:385 mptcp_pm_create_subflow_or_signal_addr+0xf9d/0x1360 net/mptcp/pm_kernel.c:355 mptcp_pm_nl_fully_established net/mptcp/pm_kernel.c:409 [inline] __mptcp_pm_kernel_worker+0x417/0x1ef0 net/mptcp/pm_kernel.c:1529 mptcp_pm_worker+0x1ee/0x320 net/mptcp/pm.c:1008 mptcp_worker+0xd5/0x1170 net/mptcp/protocol.c:2762 process_one_work kernel/workqueue.c:3263 [inline] process_scheduled_works+0xae1/0x17b0 kernel/workqueue.c:3346 worker_thread+0x8a0/0xda0 kernel/workqueue.c:3427 kthread+0x711/0x8a0 kernel/kthread.c:463 ret_from_fork+0x4bc/0x870 arch/x86/kernel/process.c:158 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245 Freed by task 6630: kasan_save_stack mm/kasan/common.c:56 [inline] kasan_save_track+0x3e/0x80 mm/kasan/common.c:77 __kasan_save_free_info+0x46/0x50 mm/kasan/generic.c:587 kasan_save_free_info mm/kasan/kasan.h:406 [inline] poison_slab_object m ---truncated--- | ||||
| CVE-2025-5254 | 2026-04-15 | 6.1 Medium | ||
| Improper Neutralization of Input During Web Page Generation (XSS or 'Cross-site Scripting') vulnerability in Kron Technologies Kron PAM allows Stored XSS.This issue affects Kron PAM: before 3.7. | ||||
| CVE-2025-52541 | 1 Amd | 1 Vivado Installation | 2026-04-15 | 7.3 High |
| A DLL hijacking vulnerability in Vivado could allow a local attacker to achieve privilege escalation, potentially resulting in arbitrary code execution. | ||||
| CVE-2025-52968 | 1 Freedesktop | 1 Xdg-utils | 2026-04-15 | 2.7 Low |
| xdg-open in xdg-utils through 1.2.1 can send requests containing SameSite=Strict cookies, which can facilitate CSRF. (For example, xdg-open could be modified to, by default, associate x-scheme-handler/https with the execution of a browser with command-line options that arrange for an empty cookie store, although this would add substantial complexity, and would not be considered a desirable or expected behavior by all users.) NOTE: this is disputed because integrations of xdg-open typically do not provide information about whether the xdg-open command and arguments were manually entered by a user, or whether they were the result of a navigation from content in an untrusted origin. | ||||
| CVE-2025-52570 | 2026-04-15 | N/A | ||
| Letmein is an authenticating port knocker. Prior to version 10.2.1, The connection limiter is implemented incorrectly. It allows an arbitrary amount of simultaneously incoming connections (TCP, UDP and Unix socket) for the services letmeind and letmeinfwd. Therefore, the command line option num-connections is not effective and does not limit the number of simultaneously incoming connections. This issue has been patched in version 10.2.1. | ||||
| CVE-2025-52993 | 2 Gnu, Nixos | 2 Guix, Nix | 2026-04-15 | 5.6 Medium |
| A race condition in the Nix, Lix, and Guix package managers enables changing the ownership of arbitrary files to the UID and GID of the build user (e.g., nixbld* or guixbuild*). This affects Nix before 2.24.15, 2.26.4, 2.28.4, and 2.29.1; Lix before 2.91.2, 2.92.2, and 2.93.1; and Guix before 1.4.0-38.0e79d5b. | ||||
| CVE-2025-52572 | 1 Hikariatama | 1 Hikka | 2026-04-15 | 10 Critical |
| Hikka, a Telegram userbot, has vulnerability affects all users on all versions of Hikka. Two scenarios are possible. 1. Web interface does not have an authenticated session: attacker can use his own Telegram account to gain RCE to the server by authorizing in the dangling web interface. 2. Web interface does have an authenticated session: due to insufficient warning in the authentication message, users were tempted to click "Allow" in the "Allow web application ops" menu. This gave an attacker access not only to remote code execution, but also to Telegram accounts of owners. Scenario number 2 is known to have been exploited in the wild. No known patches are available, but some workarounds are available. Use `--no-web` flag and do not start userbot without it; after authorizing in the web interface, close the port on the server and/or start the userbot with `--no-web` flag; and do not click "Allow" in your helper bot unless it is your explicit action that needs to be allowed. | ||||
| CVE-2024-47190 | 2026-04-15 | 2.7 Low | ||
| Northern.tech Hosted Mender before 2024.07.11 allows SSRF. | ||||