Export limit exceeded: 345430 CVEs match your query. Please refine your search to export 10,000 CVEs or fewer.
Export limit exceeded: 345430 CVEs match your query. Please refine your search to export 10,000 CVEs or fewer.
Search
Search Results (345430 CVEs found)
| CVE | Vendors | Products | Updated | CVSS v3.1 |
|---|---|---|---|---|
| CVE-2026-0810 | 2 Gitoxidelabs, Redhat | 3 Gix-date, Enterprise Linux, Logging | 2026-04-20 | 7.1 High |
| A flaw was found in gix-date. The `gix_date::parse::TimeBuf::as_str` function can generate strings containing invalid non-UTF8 characters. This issue violates the internal safety invariants of the `TimeBuf` component, leading to undefined behavior when these malformed strings are subsequently processed. This could potentially result in application instability or other unforeseen consequences. | ||||
| CVE-2025-54236 | 1 Adobe | 3 Commerce, Commerce B2b, Magento | 2026-04-20 | 9.1 Critical |
| Adobe Commerce versions 2.4.9-alpha2, 2.4.8-p2, 2.4.7-p7, 2.4.6-p12, 2.4.5-p14, 2.4.4-p15 and earlier are affected by an Improper Input Validation vulnerability. A successful attacker can abuse this to achieve session takeover, increasing the confidentiality, and integrity impact to high. Exploitation of this issue does not require user interaction. | ||||
| CVE-2025-54550 | 1 Apache | 1 Airflow | 2026-04-19 | 8.1 High |
| The example example_xcom that was included in airflow documentation implemented unsafe pattern of reading value from xcom in the way that could be exploited to allow UI user who had access to modify XComs to perform arbitrary execution of code on the worker. Since the UI users are already highly trusted, this is a Low severity vulnerability. It does not affect Airflow release - example_dags are not supposed to be enabled in production environment, however users following the example could replicate the bad pattern. Documentation of Airflow 3.2.0 contains version of the example with improved resiliance for that case. Users who followed that pattern are advised to adjust their implementations accordingly. | ||||
| CVE-2026-1603 | 1 Ivanti | 1 Endpoint Manager | 2026-04-19 | 8.6 High |
| An authentication bypass in Ivanti Endpoint Manager before version 2024 SU5 allows a remote unauthenticated attacker to leak specific stored credential data. | ||||
| CVE-2026-21533 | 1 Microsoft | 30 Windows 10 1607, Windows 10 1809, Windows 10 21h2 and 27 more | 2026-04-19 | 7.8 High |
| Improper privilege management in Windows Remote Desktop allows an authorized attacker to elevate privileges locally. | ||||
| CVE-2026-21513 | 1 Microsoft | 30 Windows 10 1607, Windows 10 1809, Windows 10 21h2 and 27 more | 2026-04-19 | 8.8 High |
| Protection mechanism failure in MSHTML Framework allows an unauthorized attacker to bypass a security feature over a network. | ||||
| CVE-2026-0926 | 2 Prodigycommerce, Wordpress | 2 Prodigy Commerce, Wordpress | 2026-04-19 | 9.8 Critical |
| The Prodigy Commerce plugin for WordPress is vulnerable to Local File Inclusion in all versions up to, and including, 3.3.0 via the 'parameters[template_name]' parameter. This makes it possible for unauthenticated attackers to include and read arbitrary files or execute arbitrary files on the server, allowing the execution of any PHP code in those files. This can be used to bypass access controls, obtain sensitive data, or achieve code execution in cases where images and other “safe” file types can be uploaded and included. | ||||
| CVE-2026-6158 | 1 Totolink | 2 N300rh, N300rh Firmware | 2026-04-19 | 7.3 High |
| A flaw has been found in Totolink N300RH 6.1c.1353_B20190305. Affected is the function setUpgradeUboot of the file upgrade.so. This manipulation of the argument FileName causes os command injection. The attack is possible to be carried out remotely. The exploit has been published and may be used. | ||||
| CVE-2019-25685 | 1 Phpbb | 1 Phpbb | 2026-04-19 | N/A |
| This CVE ID has been rejected or withdrawn by its CVE Numbering Authority. | ||||
| CVE-2024-4024 | 1 Gitlab | 1 Gitlab | 2026-04-19 | 7.3 High |
| An issue has been discovered in GitLab CE/EE affecting all versions starting from 7.8 before 16.9.6, all versions starting from 16.10 before 16.10.4, all versions starting from 16.11 before 16.11.1. Under certain conditions, an attacker with their Bitbucket account credentials may be able to take over a GitLab account linked to another user's Bitbucket account, if Bitbucket is used as an OAuth 2.0 provider on GitLab. | ||||
| CVE-2024-4006 | 1 Gitlab | 1 Gitlab | 2026-04-19 | 4.3 Medium |
| An issue has been discovered in GitLab CE/EE affecting all versions starting from 16.7 before 16.9.6, all versions starting from 16.10 before 16.10.4, all versions starting from 16.11 before 16.11.1 where personal access scopes were not honored by GraphQL subscriptions | ||||
| CVE-2026-6056 | 2026-04-18 | N/A | ||
| This CVE ID has been rejected or withdrawn by its CVE Numbering Authority. | ||||
| CVE-2026-21708 | 1 Veeam | 1 Backup And Recovery | 2026-04-18 | N/A |
| A vulnerability allowing a Backup Viewer to perform remote code execution (RCE) as the postgres user. | ||||
| CVE-2026-41113 | 1 Sagredo | 1 Qmail | 2026-04-18 | 8.1 High |
| sagredo qmail before 2026.04.07 allows tls_quit remote code execution because of popen in notlshosts_auto in qmail-remote.c. | ||||
| CVE-2026-23106 | 1 Linux | 1 Linux Kernel | 2026-04-18 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: timekeeping: Adjust the leap state for the correct auxiliary timekeeper When __do_ajdtimex() was introduced to handle adjtimex for any timekeeper, this reference to tk_core was not updated. When called on an auxiliary timekeeper, the core timekeeper would be updated incorrectly. This gets caught by the lock debugging diagnostics because the timekeepers sequence lock gets written to without holding its associated spinlock: WARNING: include/linux/seqlock.h:226 at __do_adjtimex+0x394/0x3b0, CPU#2: test/125 aux_clock_adj (kernel/time/timekeeping.c:2979) __do_sys_clock_adjtime (kernel/time/posix-timers.c:1161 kernel/time/posix-timers.c:1173) do_syscall_64 (arch/x86/entry/syscall_64.c:63 (discriminator 1) arch/x86/entry/syscall_64.c:94 (discriminator 1)) entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:131) Update the correct auxiliary timekeeper. | ||||
| CVE-2026-33439 | 1 Openidentityplatform | 1 Openam | 2026-04-18 | 9.8 Critical |
| Open Access Management (OpenAM) is an access management solution. Prior to 16.0.6, OpenIdentityPlatform OpenAM is vulnerable to pre-authentication Remote Code Execution (RCE) via unsafe Java deserialization of the jato.clientSession HTTP parameter. This bypasses the WhitelistObjectInputStream mitigation that was applied to the jato.pageSession parameter after CVE-2021-35464. An unauthenticated attacker can achieve arbitrary command execution on the server by sending a crafted serialized Java object as the jato.clientSession GET/POST parameter to any JATO ViewBean endpoint whose JSP contains <jato:form> tags (e.g., the Password Reset pages). This vulnerability is fixed in 16.0.6. | ||||
| CVE-2026-24839 | 1 Dokploy | 1 Dokploy | 2026-04-18 | 4.7 Medium |
| Dokploy is a free, self-hostable Platform as a Service (PaaS). In versions prior to 0.26.6, the Dokploy web interface is vulnerable to Clickjacking attacks due to missing frame-busting headers. This allows attackers to embed Dokploy pages in malicious iframes and trick authenticated users into performing unintended actions. Version 0.26.6 patches the issue. | ||||
| CVE-2026-23031 | 1 Linux | 1 Linux Kernel | 2026-04-18 | 7.0 High |
| In the Linux kernel, the following vulnerability has been resolved: can: gs_usb: gs_usb_receive_bulk_callback(): fix URB memory leak In gs_can_open(), the URBs for USB-in transfers are allocated, added to the parent->rx_submitted anchor and submitted. In the complete callback gs_usb_receive_bulk_callback(), the URB is processed and resubmitted. In gs_can_close() the URBs are freed by calling usb_kill_anchored_urbs(parent->rx_submitted). However, this does not take into account that the USB framework unanchors the URB before the complete function is called. This means that once an in-URB has been completed, it is no longer anchored and is ultimately not released in gs_can_close(). Fix the memory leak by anchoring the URB in the gs_usb_receive_bulk_callback() to the parent->rx_submitted anchor. | ||||
| CVE-2026-23100 | 1 Linux | 1 Linux Kernel | 2026-04-18 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: mm/hugetlb: fix hugetlb_pmd_shared() Patch series "mm/hugetlb: fixes for PMD table sharing (incl. using mmu_gather)", v3. One functional fix, one performance regression fix, and two related comment fixes. I cleaned up my prototype I recently shared [1] for the performance fix, deferring most of the cleanups I had in the prototype to a later point. While doing that I identified the other things. The goal of this patch set is to be backported to stable trees "fairly" easily. At least patch #1 and #4. Patch #1 fixes hugetlb_pmd_shared() not detecting any sharing Patch #2 + #3 are simple comment fixes that patch #4 interacts with. Patch #4 is a fix for the reported performance regression due to excessive IPI broadcasts during fork()+exit(). The last patch is all about TLB flushes, IPIs and mmu_gather. Read: complicated There are plenty of cleanups in the future to be had + one reasonable optimization on x86. But that's all out of scope for this series. Runtime tested, with a focus on fixing the performance regression using the original reproducer [2] on x86. This patch (of 4): We switched from (wrongly) using the page count to an independent shared count. Now, shared page tables have a refcount of 1 (excluding speculative references) and instead use ptdesc->pt_share_count to identify sharing. We didn't convert hugetlb_pmd_shared(), so right now, we would never detect a shared PMD table as such, because sharing/unsharing no longer touches the refcount of a PMD table. Page migration, like mbind() or migrate_pages() would allow for migrating folios mapped into such shared PMD tables, even though the folios are not exclusive. In smaps we would account them as "private" although they are "shared", and we would be wrongly setting the PM_MMAP_EXCLUSIVE in the pagemap interface. Fix it by properly using ptdesc_pmd_is_shared() in hugetlb_pmd_shared(). | ||||
| CVE-2026-23143 | 1 Linux | 1 Linux Kernel | 2026-04-18 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: virtio_net: Fix misalignment bug in struct virtnet_info Use the new TRAILING_OVERLAP() helper to fix a misalignment bug along with the following warning: drivers/net/virtio_net.c:429:46: warning: structure containing a flexible array member is not at the end of another structure [-Wflex-array-member-not-at-end] This helper creates a union between a flexible-array member (FAM) and a set of members that would otherwise follow it (in this case `u8 rss_hash_key_data[VIRTIO_NET_RSS_MAX_KEY_SIZE];`). This overlays the trailing members (rss_hash_key_data) onto the FAM (hash_key_data) while keeping the FAM and the start of MEMBERS aligned. The static_assert() ensures this alignment remains. Notice that due to tail padding in flexible `struct virtio_net_rss_config_trailer`, `rss_trailer.hash_key_data` (at offset 83 in struct virtnet_info) and `rss_hash_key_data` (at offset 84 in struct virtnet_info) are misaligned by one byte. See below: struct virtio_net_rss_config_trailer { __le16 max_tx_vq; /* 0 2 */ __u8 hash_key_length; /* 2 1 */ __u8 hash_key_data[]; /* 3 0 */ /* size: 4, cachelines: 1, members: 3 */ /* padding: 1 */ /* last cacheline: 4 bytes */ }; struct virtnet_info { ... struct virtio_net_rss_config_trailer rss_trailer; /* 80 4 */ /* XXX last struct has 1 byte of padding */ u8 rss_hash_key_data[40]; /* 84 40 */ ... /* size: 832, cachelines: 13, members: 48 */ /* sum members: 801, holes: 8, sum holes: 31 */ /* paddings: 2, sum paddings: 5 */ }; After changes, those members are correctly aligned at offset 795: struct virtnet_info { ... union { struct virtio_net_rss_config_trailer rss_trailer; /* 792 4 */ struct { unsigned char __offset_to_hash_key_data[3]; /* 792 3 */ u8 rss_hash_key_data[40]; /* 795 40 */ }; /* 792 43 */ }; /* 792 44 */ ... /* size: 840, cachelines: 14, members: 47 */ /* sum members: 801, holes: 8, sum holes: 35 */ /* padding: 4 */ /* paddings: 1, sum paddings: 4 */ /* last cacheline: 8 bytes */ }; As a result, the RSS key passed to the device is shifted by 1 byte: the last byte is cut off, and instead a (possibly uninitialized) byte is added at the beginning. As a last note `struct virtio_net_rss_config_hdr *rss_hdr;` is also moved to the end, since it seems those three members should stick around together. :) | ||||