Export limit exceeded: 11157 CVEs match your query. Please refine your search to export 10,000 CVEs or fewer.
Search
Search Results (11157 CVEs found)
| CVE | Vendors | Products | Updated | CVSS v3.1 |
|---|---|---|---|---|
| CVE-2025-56643 | 1 Requarks | 1 Wiki.js | 2025-12-31 | 9.1 Critical |
| Requarks Wiki.js 2.5.307 does not properly revoke or invalidate active JWT tokens when a user logs out. As a result, previously issued tokens remain valid and can be reused to access the system, even after logout. This behavior affects session integrity and may allow unauthorized access if a token is compromised. The issue is present in the authentication resolver logic and affects both the GraphQL endpoint and the logout mechanism. | ||||
| CVE-2024-56143 | 1 Strapi | 1 Strapi | 2025-12-31 | 8.2 High |
| Strapi is an open-source headless content management system. In versions from 5.0.0 to before 5.5.2, the lookup operator provided by the document service does not properly sanitize query parameters for private fields. An attacker can access private fields, including admin passwords and reset tokens, by crafting queries with the lookup parameter. This vulnerability is fixed in 5.5.2. | ||||
| CVE-2024-53406 | 1 Espressif | 1 Esp-idf | 2025-12-31 | 8.8 High |
| Espressif Esp idf v5.3.0 is vulnerable to Insecure Permissions resulting in Authentication bypass. In the reconnection phase, the device reuses the session key from a previous connection session, creating an opportunity for attackers to execute security bypass attacks. | ||||
| CVE-2025-64012 | 1 Invoiceplane | 1 Invoiceplane | 2025-12-31 | 4.3 Medium |
| InvoicePlane commit debb446c is vulnerable to Incorrect Access Control. The invoices/view handler fails to verify ownership before returning invoice data. | ||||
| CVE-2025-65318 | 2 Canarymail, Microsoft | 2 Canary Mail, Windows | 2025-12-31 | 9.1 Critical |
| When using the attachment interaction functionality, Canary Mail 5.1.40 and below saves documents to a file system without a Mark-of-the-Web tag, which allows attackers to bypass the built-in file protection mechanisms of both Windows OS and third-party software. | ||||
| CVE-2025-65319 | 1 Blixhq | 1 Bluemail | 2025-12-31 | 9.1 Critical |
| When using the attachment interaction functionality, Blue Mail 1.140.103 and below saves documents to a file system without a Mark-of-the-Web tag, which allows attackers to bypass the built-in file protection mechanisms of both Windows OS and third-party software. | ||||
| CVE-2025-52552 | 1 Fastgpt | 1 Fastgpt | 2025-12-29 | 6.1 Medium |
| FastGPT is an AI Agent building platform. Prior to version 4.9.12, the LastRoute Parameter on login page is vulnerable to open redirect and DOM-based XSS. Improper validation and lack of sanitization of this parameter allows attackers execute malicious JavaScript or redirect them to attacker-controlled sites. This issue has been patched in version 4.9.12. | ||||
| CVE-2025-62690 | 1 Mattermost | 2 Mattermost, Mattermost Server | 2025-12-29 | 3.1 Low |
| Mattermost versions 10.11.x <= 10.11.4 fail to validate redirect URLs on the /error page, which allows an attacker to redirect a victim to a malicious site via a crafted link opened in a new tab. | ||||
| CVE-2024-12289 | 1 Hashicorp | 1 Boundary | 2025-12-29 | 5.9 Medium |
| Boundary Community Edition and Boundary Enterprise (“Boundary”) incorrectly handle HTTP requests during the initialization of the Boundary controller, which may cause the Boundary server to terminate prematurely. Boundary is only vulnerable to this flaw during the initialization of the Boundary controller, which on average is measured in milliseconds during the Boundary startup process. This vulnerability, CVE-2024-12289, is fixed in Boundary Community Edition and Boundary Enterprise 0.16.4, 0.17.3, 0.18.2. | ||||
| CVE-2024-7625 | 1 Hashicorp | 1 Nomad | 2025-12-29 | 5.8 Medium |
| In HashiCorp Nomad and Nomad Enterprise from 0.6.1 up to 1.6.13, 1.7.10, and 1.8.2, the archive unpacking process is vulnerable to writes outside the allocation directory during migration of allocation directories when multiple archive headers target the same file. This vulnerability, CVE-2024-7625, is fixed in Nomad 1.6.14, 1.7.11, and 1.8.3. Access or compromise of the Nomad client agent at the source allocation first is a prerequisite for leveraging this vulnerability. | ||||
| CVE-2025-50433 | 1 Monnit | 1 Imonnit | 2025-12-29 | 9.8 Critical |
| An issue was discovered in imonnit.com (2025-04-24) allowing malicious actors to gain escalated privileges via crafted password reset to take over arbitrary user accounts. | ||||
| CVE-2025-1889 | 1 Mmaitre314 | 1 Picklescan | 2025-12-29 | 9.8 Critical |
| picklescan before 0.0.22 only considers standard pickle file extensions in the scope for its vulnerability scan. An attacker could craft a malicious model that uses Pickle and include a malicious pickle file with a non-standard file extension. Because the malicious pickle file inclusion is not considered as part of the scope of picklescan, the file would pass security checks and appear to be safe, when it could instead prove to be problematic. | ||||
| CVE-2024-58317 | 1 Kentico | 1 Xperience | 2025-12-24 | 5.3 Medium |
| A cookie security configuration vulnerability in Kentico Xperience allows attackers to bypass SSL requirements when setting administration cookies via web.config. The vulnerability affects .NET Framework projects by incorrectly handling the 'requireSSL' attribute, potentially compromising session security and authentication state. | ||||
| CVE-2025-11247 | 1 Gitlab | 1 Gitlab | 2025-12-23 | 4.3 Medium |
| GitLab has remediated an issue in GitLab EE affecting all versions from 13.2 before 18.4.6, 18.5 before 18.5.4, and 18.6 before 18.6.2 that could have allowed an authenticated user to disclose sensitive information from private projects by executing specifically crafted GraphQL queries. | ||||
| CVE-2024-21492 | 2 Authcrunch, Greenpau | 2 Caddy-security, Caddy-security | 2025-12-23 | 4.8 Medium |
| All versions of the package github.com/greenpau/caddy-security are vulnerable to Insufficient Session Expiration due to improper user session invalidation upon clicking the "Sign Out" button. User sessions remain valid even after requests are sent to /logout and /oauth2/google/logout. Attackers who gain access to an active but supposedly logged-out session can perform unauthorized actions on behalf of the user. | ||||
| CVE-2024-27005 | 1 Linux | 1 Linux Kernel | 2025-12-23 | 6.3 Medium |
| In the Linux kernel, the following vulnerability has been resolved: interconnect: Don't access req_list while it's being manipulated The icc_lock mutex was split into separate icc_lock and icc_bw_lock mutexes in [1] to avoid lockdep splats. However, this didn't adequately protect access to icc_node::req_list. The icc_set_bw() function will eventually iterate over req_list while only holding icc_bw_lock, but req_list can be modified while only holding icc_lock. This causes races between icc_set_bw(), of_icc_get(), and icc_put(). Example A: CPU0 CPU1 ---- ---- icc_set_bw(path_a) mutex_lock(&icc_bw_lock); icc_put(path_b) mutex_lock(&icc_lock); aggregate_requests() hlist_for_each_entry(r, ... hlist_del(... <r = invalid pointer> Example B: CPU0 CPU1 ---- ---- icc_set_bw(path_a) mutex_lock(&icc_bw_lock); path_b = of_icc_get() of_icc_get_by_index() mutex_lock(&icc_lock); path_find() path_init() aggregate_requests() hlist_for_each_entry(r, ... hlist_add_head(... <r = invalid pointer> Fix this by ensuring icc_bw_lock is always held before manipulating icc_node::req_list. The additional places icc_bw_lock is held don't perform any memory allocations, so we should still be safe from the original lockdep splats that motivated the separate locks. [1] commit af42269c3523 ("interconnect: Fix locking for runpm vs reclaim") | ||||
| CVE-2022-49434 | 2 Linux, Redhat | 2 Linux Kernel, Enterprise Linux | 2025-12-23 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: PCI: Avoid pci_dev_lock() AB/BA deadlock with sriov_numvfs_store() The sysfs sriov_numvfs_store() path acquires the device lock before the config space access lock: sriov_numvfs_store device_lock # A (1) acquire device lock sriov_configure vfio_pci_sriov_configure # (for example) vfio_pci_core_sriov_configure pci_disable_sriov sriov_disable pci_cfg_access_lock pci_wait_cfg # B (4) wait for dev->block_cfg_access == 0 Previously, pci_dev_lock() acquired the config space access lock before the device lock: pci_dev_lock pci_cfg_access_lock dev->block_cfg_access = 1 # B (2) set dev->block_cfg_access = 1 device_lock # A (3) wait for device lock Any path that uses pci_dev_lock(), e.g., pci_reset_function(), may deadlock with sriov_numvfs_store() if the operations occur in the sequence (1) (2) (3) (4). Avoid the deadlock by reversing the order in pci_dev_lock() so it acquires the device lock before the config space access lock, the same as the sriov_numvfs_store() path. [bhelgaas: combined and adapted commit log from Jay Zhou's independent subsequent posting: https://lore.kernel.org/r/20220404062539.1710-1-jianjay.zhou@huawei.com] | ||||
| CVE-2022-50293 | 1 Linux | 1 Linux Kernel | 2025-12-23 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: btrfs: do not BUG_ON() on ENOMEM when dropping extent items for a range If we get -ENOMEM while dropping file extent items in a given range, at btrfs_drop_extents(), due to failure to allocate memory when attempting to increment the reference count for an extent or drop the reference count, we handle it with a BUG_ON(). This is excessive, instead we can simply abort the transaction and return the error to the caller. In fact most callers of btrfs_drop_extents(), directly or indirectly, already abort the transaction if btrfs_drop_extents() returns any error. Also, we already have error paths at btrfs_drop_extents() that may return -ENOMEM and in those cases we abort the transaction, like for example anything that changes the b+tree may return -ENOMEM due to a failure to allocate a new extent buffer when COWing an existing extent buffer, such as a call to btrfs_duplicate_item() for example. So replace the BUG_ON() calls with proper logic to abort the transaction and return the error. | ||||
| CVE-2022-49879 | 1 Linux | 1 Linux Kernel | 2025-12-23 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: ext4: fix BUG_ON() when directory entry has invalid rec_len The rec_len field in the directory entry has to be a multiple of 4. A corrupted filesystem image can be used to hit a BUG() in ext4_rec_len_to_disk(), called from make_indexed_dir(). ------------[ cut here ]------------ kernel BUG at fs/ext4/ext4.h:2413! ... RIP: 0010:make_indexed_dir+0x53f/0x5f0 ... Call Trace: <TASK> ? add_dirent_to_buf+0x1b2/0x200 ext4_add_entry+0x36e/0x480 ext4_add_nondir+0x2b/0xc0 ext4_create+0x163/0x200 path_openat+0x635/0xe90 do_filp_open+0xb4/0x160 ? __create_object.isra.0+0x1de/0x3b0 ? _raw_spin_unlock+0x12/0x30 do_sys_openat2+0x91/0x150 __x64_sys_open+0x6c/0xa0 do_syscall_64+0x3c/0x80 entry_SYSCALL_64_after_hwframe+0x46/0xb0 The fix simply adds a call to ext4_check_dir_entry() to validate the directory entry, returning -EFSCORRUPTED if the entry is invalid. | ||||
| CVE-2022-49765 | 1 Linux | 1 Linux Kernel | 2025-12-23 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: net/9p: use a dedicated spinlock for trans_fd Shamelessly copying the explanation from Tetsuo Handa's suggested patch[1] (slightly reworded): syzbot is reporting inconsistent lock state in p9_req_put()[2], for p9_tag_remove() from p9_req_put() from IRQ context is using spin_lock_irqsave() on "struct p9_client"->lock but trans_fd (not from IRQ context) is using spin_lock(). Since the locks actually protect different things in client.c and in trans_fd.c, just replace trans_fd.c's lock by a new one specific to the transport (client.c's protect the idr for fid/tag allocations, while trans_fd.c's protects its own req list and request status field that acts as the transport's state machine) | ||||