Export limit exceeded: 367374 CVEs match your query. Please refine your search to export 10,000 CVEs or fewer.
Search
Search Results (367374 CVEs found)
| CVE | Vendors | Products | Updated | CVSS v3.1 |
|---|---|---|---|---|
| CVE-2024-45101 | 1 Lenovo | 1 Xclarity Administrator | 2026-04-15 | 6.8 Medium |
| A privilege escalation vulnerability was discovered when Single Sign On (SSO) is enabled that could allow an attacker to intercept a valid, authenticated LXCA user’s XCC session if they can convince the user to click on a specially crafted URL. | ||||
| CVE-2024-45351 | 2026-04-15 | 7.8 High | ||
| A code execution vulnerability exists in the Xiaomi Game center application product. The vulnerability is caused by improper input validation and can be exploited by attackers to execute malicious code. | ||||
| CVE-2025-13375 | 1 Ibm | 1 Common Cryptographic Architecture | 2026-04-15 | 9.8 Critical |
| IBM Common Cryptographic Architecture (CCA) 7.5.52 and 8.4.82 could allow an unauthenticated user to execute arbitrary commands with elevated privileges on the system. | ||||
| CVE-2025-68821 | 1 Linux | 1 Linux Kernel | 2026-04-15 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: fuse: fix readahead reclaim deadlock Commit e26ee4efbc79 ("fuse: allocate ff->release_args only if release is needed") skips allocating ff->release_args if the server does not implement open. However in doing so, fuse_prepare_release() now skips grabbing the reference on the inode, which makes it possible for an inode to be evicted from the dcache while there are inflight readahead requests. This causes a deadlock if the server triggers reclaim while servicing the readahead request and reclaim attempts to evict the inode of the file being read ahead. Since the folio is locked during readahead, when reclaim evicts the fuse inode and fuse_evict_inode() attempts to remove all folios associated with the inode from the page cache (truncate_inode_pages_range()), reclaim will block forever waiting for the lock since readahead cannot relinquish the lock because it is itself blocked in reclaim: >>> stack_trace(1504735) folio_wait_bit_common (mm/filemap.c:1308:4) folio_lock (./include/linux/pagemap.h:1052:3) truncate_inode_pages_range (mm/truncate.c:336:10) fuse_evict_inode (fs/fuse/inode.c:161:2) evict (fs/inode.c:704:3) dentry_unlink_inode (fs/dcache.c:412:3) __dentry_kill (fs/dcache.c:615:3) shrink_kill (fs/dcache.c:1060:12) shrink_dentry_list (fs/dcache.c:1087:3) prune_dcache_sb (fs/dcache.c:1168:2) super_cache_scan (fs/super.c:221:10) do_shrink_slab (mm/shrinker.c:435:9) shrink_slab (mm/shrinker.c:626:10) shrink_node (mm/vmscan.c:5951:2) shrink_zones (mm/vmscan.c:6195:3) do_try_to_free_pages (mm/vmscan.c:6257:3) do_swap_page (mm/memory.c:4136:11) handle_pte_fault (mm/memory.c:5562:10) handle_mm_fault (mm/memory.c:5870:9) do_user_addr_fault (arch/x86/mm/fault.c:1338:10) handle_page_fault (arch/x86/mm/fault.c:1481:3) exc_page_fault (arch/x86/mm/fault.c:1539:2) asm_exc_page_fault+0x22/0x27 Fix this deadlock by allocating ff->release_args and grabbing the reference on the inode when preparing the file for release even if the server does not implement open. The inode reference will be dropped when the last reference on the fuse file is dropped (see fuse_file_put() -> fuse_release_end()). | ||||
| CVE-2025-13472 | 1 Perforce | 1 Blazemeter | 2026-04-15 | N/A |
| A fix was made in BlazeMeter Jenkins Plugin version 4.27 to allow users only with certain permissions to see the list of available resources like credential IDs, bzm workspaces and bzm project Ids. Prior to this fix, anyone could see this list as a dropdown on the Jenkins UI. | ||||
| CVE-2025-68947 | 1 Nsecsoft | 1 Nscknl | 2026-04-15 | 4.7 Medium |
| NSecsoft 'NSecKrnl' is a Windows driver that allows a local, authenticated attacker to terminate processes owned by other users, including SYSTEM and Protected Processes by issuing crafted IOCTL requests to the driver. | ||||
| CVE-2025-13491 | 1 Ibm | 1 App Connect Enterprise Certified Container | 2026-04-15 | 5.1 Medium |
| IBM App Connect Enterprise Certified Container CD: 11.2.0 through 11.6.0, 12.1.0 through 12.19.0 and 12.0 LTS: 12.0.0 through 12.0.19 could allow an attacker to access sensitive files or modify configurations due to an untrusted search path. | ||||
| CVE-2025-13488 | 1 Sonatype | 1 Nexus Repository Manager | 2026-04-15 | N/A |
| Due to a regression introduced in version 3.83.0, a security header is no longer applied to certain user-uploaded content served from repositories. This may allow an authenticated attacker with repository upload privileges to exploit a stored cross-site scripting (XSS) vulnerability with user context. | ||||
| CVE-2025-13653 | 1 Search-guard | 1 Search Guard | 2026-04-15 | 4.3 Medium |
| In Search Guard FLX versions from 3.1.0 up to 4.0.0 with enterprise modules being disabled, there exists an issue which allows authenticated users to use specially crafted requests to read documents from data streams without having the respective privileges. | ||||
| CVE-2025-71064 | 1 Linux | 1 Linux Kernel | 2026-04-15 | 7.0 High |
| In the Linux kernel, the following vulnerability has been resolved: net: hns3: using the num_tqps in the vf driver to apply for resources Currently, hdev->htqp is allocated using hdev->num_tqps, and kinfo->tqp is allocated using kinfo->num_tqps. However, kinfo->num_tqps is set to min(new_tqps, hdev->num_tqps); Therefore, kinfo->num_tqps may be smaller than hdev->num_tqps, which causes some hdev->htqp[i] to remain uninitialized in hclgevf_knic_setup(). Thus, this patch allocates hdev->htqp and kinfo->tqp using hdev->num_tqps, ensuring that the lengths of hdev->htqp and kinfo->tqp are consistent and that all elements are properly initialized. | ||||
| CVE-2025-71067 | 1 Linux | 1 Linux Kernel | 2026-04-15 | N/A |
| In the Linux kernel, the following vulnerability has been resolved: ntfs: set dummy blocksize to read boot_block when mounting When mounting, sb->s_blocksize is used to read the boot_block without being defined or validated. Set a dummy blocksize before attempting to read the boot_block. The issue can be triggered with the following syz reproducer: mkdirat(0xffffffffffffff9c, &(0x7f0000000080)='./file1\x00', 0x0) r4 = openat$nullb(0xffffffffffffff9c, &(0x7f0000000040), 0x121403, 0x0) ioctl$FS_IOC_SETFLAGS(r4, 0x40081271, &(0x7f0000000980)=0x4000) mount(&(0x7f0000000140)=@nullb, &(0x7f0000000040)='./cgroup\x00', &(0x7f0000000000)='ntfs3\x00', 0x2208004, 0x0) syz_clone(0x88200200, 0x0, 0x0, 0x0, 0x0, 0x0) Here, the ioctl sets the bdev block size to 16384. During mount, get_tree_bdev_flags() calls sb_set_blocksize(sb, block_size(bdev)), but since block_size(bdev) > PAGE_SIZE, sb_set_blocksize() leaves sb->s_blocksize at zero. Later, ntfs_init_from_boot() attempts to read the boot_block while sb->s_blocksize is still zero, which triggers the bug. [almaz.alexandrovich@paragon-software.com: changed comment style, added return value handling] | ||||
| CVE-2025-68784 | 1 Linux | 1 Linux Kernel | 2026-04-15 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: xfs: fix a UAF problem in xattr repair The xchk_setup_xattr_buf function can allocate a new value buffer, which means that any reference to ab->value before the call could become a dangling pointer. Fix this by moving an assignment to after the buffer setup. | ||||
| CVE-2024-38798 | 1 Tianocore | 1 Edk2 | 2026-04-15 | 5.2 Medium |
| EDK2 contains a vulnerability in BIOS where an attacker may cause “Exposure of Sensitive Information to an Unauthorized Actor” by local access. Successful exploitation of this vulnerability will lead to possible information disclosure or escalation of privilege and impact Confidentiality. | ||||
| CVE-2024-36355 | 1 Amd | 25 Epyc 9004 Series Processors, Epyc Embedded 9004 Series Processors, Ryzen 5000 Series Desktop Processors and 22 more | 2026-04-15 | N/A |
| Improper input validation in the SMM handler could allow an attacker with Ring0 access to write to SMRAM and modify execution flow for S3 (sleep) wake up, potentially resulting in arbitrary code execution. | ||||
| CVE-2024-36324 | 1 Amd | 25 Amd Ryzen™ Ai 300 Series Processors, Radeon Pro V520, Radeon Pro V620 and 22 more | 2026-04-15 | 8.8 High |
| Improper input validation in AMD Graphics Driver could allow an attacker to supply a specially crafted pointer, potentially leading to arbitrary code execution. | ||||
| CVE-2024-36320 | 1 Amd | 28 Radeon Pro Vii, Radeon Pro W5000 Series, Radeon Pro W6000 Series and 25 more | 2026-04-15 | N/A |
| Integer Overflow within atihdwt6.sys can allow a local attacker to cause out of bound read/write potentially leading to loss of confidentiality, integrity and availability | ||||
| CVE-2024-36319 | 1 Amd | 14 Instinct Mi300a, Instinct Mi300x, Instinct Mi308x and 11 more | 2026-04-15 | N/A |
| Debug code left active in AMD's Video Decoder Engine Firmware (VCN FW) could allow a attacker to submit a maliciously crafted command causing the VCN FW to perform read/writes HW registers, potentially impacting confidentiality, integrity and availabilability of the system. | ||||
| CVE-2024-36316 | 1 Amd | 19 Radeon Pro V520, Radeon Pro V620, Radeon Pro V710 and 16 more | 2026-04-15 | 5.5 Medium |
| The integer overflow vulnerability within AMD Graphics driver could allow an attacker to bypass size checks potentially resulting in a denial of service | ||||
| CVE-2024-36311 | 1 Amd | 5 Ryzen 5000 Series Desktop Processors, Ryzen 7000 Series Desktop Processors, Ryzen 7040 Series Mobile Processors With Radeon Graphics and 2 more | 2026-04-15 | N/A |
| A Time-of-check time-of-use (TOCTOU) race condition in the SMM communications buffer could allow a privileged attacker to bypass input validation and perform an out of bounds read or write, potentially resulting in loss of confidentiality, integrity, or availability. | ||||
| CVE-2024-36310 | 1 Amd | 15 Epyc 9004 Series Processors, Epyc 9005 Series Processors, Epyc Embedded 9004 Series Processors and 12 more | 2026-04-15 | N/A |
| Improper input validation in the SMM communications buffer could allow a privileged attacker to perform an out of bounds read or write to SMRAM potentially resulting in loss of confidentiality or integrity. | ||||