Export limit exceeded: 10315 CVEs match your query. Please refine your search to export 10,000 CVEs or fewer.
Search
Search Results (10315 CVEs found)
| CVE | Vendors | Products | Updated | CVSS v3.1 |
|---|---|---|---|---|
| CVE-2025-2418 | 1 Tr7 Cyber defense Inc. | 1 Web Application Firewall | 2026-03-25 | 4.3 Medium |
| URL Redirection to Untrusted Site ('Open Redirect') vulnerability in TR7 Cyber Defense Inc. Web Application Firewall allows Phishing.This issue affects Web Application Firewall: from 4.30 through 16022026. NOTE: The vendor was contacted early about this disclosure but did not respond in any way. | ||||
| CVE-2025-10947 | 2026-03-25 | 5.3 Medium | ||
| A flaw has been found in Sistemas Pleno Gestão de Locação up to 2025.7.x. The impacted element is an unknown function of the file /api/areacliente/pessoa/validarCpf of the component CPF Handler. Executing a manipulation of the argument pes_cpf can lead to authorization bypass. The attack can be executed remotely. The exploit has been published and may be used. Upgrading to version 2025.8.0 is sufficient to resolve this issue. It is advisable to upgrade the affected component. | ||||
| CVE-2026-25744 | 2 Open-emr, Openemr | 2 Openemr, Openemr | 2026-03-25 | 6.5 Medium |
| OpenEMR is a free and open source electronic health records and medical practice management application. Prior to 8.0.0.2, the encounter vitals API accepts an `id` in the request body and treats it as an UPDATE. There is no verification that the vital belongs to the current patient or encounter. An authenticated user with encounters/notes permission can overwrite any patient's vitals by supplying another patient's vital `id`, leading to medical record tampering. Version 8.0.0.2 fixes the issue. | ||||
| CVE-2026-33304 | 2 Open-emr, Openemr | 2 Openemr, Openemr | 2026-03-25 | 6.5 Medium |
| OpenEMR is a free and open source electronic health records and medical practice management application. Prior to 8.0.0.2, an authorization bypass in the dated reminders log allows any authenticated non-admin user to view reminder messages belonging to other users, including associated patient names and free-text message content, by crafting a GET request with arbitrary user IDs in the `sentTo[]` or `sentBy[]` parameters. Version 8.0.0.2 fixes the issue. | ||||
| CVE-2026-33305 | 2 Open-emr, Openemr | 2 Openemr, Openemr | 2026-03-25 | 5.4 Medium |
| OpenEMR is a free and open source electronic health records and medical practice management application. Prior to 8.0.0.2, an authorization bypass in the optional FaxSMS module (`oe-module-faxsms`) allows any authenticated OpenEMR user to invoke controller methods — including `getNotificationLog()`, which returns patient appointment data (PHI) — regardless of whether they hold the required ACL permissions. The `AppDispatch` constructor dispatches user-controlled actions and exits the process before any calling code can enforce ACL checks. Version 8.0.0.2 fixes the issue. | ||||
| CVE-2026-29105 | 1 Suitecrm | 1 Suitecrm | 2026-03-25 | 5.4 Medium |
| SuiteCRM is an open-source, enterprise-ready Customer Relationship Management (CRM) software application. Prior to versions 7.15.1 and 8.9.3, SuiteCRM contains an unauthenticated open redirect vulnerability in the WebToLead capture functionality. A user-supplied POST parameter is used as a redirect destination without validation, allowing attackers to redirect victims to arbitrary external websites. This vulnerability allows attackers to abuse the trusted SuiteCRM domain for phishing and social engineering attacks by redirecting users to malicious external websites. Versions 7.15.1 and 8.9.3 patch the issue. | ||||
| CVE-2026-29189 | 1 Suitecrm | 1 Suitecrm | 2026-03-25 | 8.1 High |
| SuiteCRM is an open-source, enterprise-ready Customer Relationship Management (CRM) software application. Prior to versions 7.15.1 and 8.9.3, the SuiteCRM REST API V8 has missing ACL (Access Control List) checks on several endpoints, allowing authenticated users to access and manipulate data they should not have permission to interact with. Versions 7.15.1 and 8.9.3 patch the issue. | ||||
| CVE-2026-33265 | 1 Librechat | 1 Librechat | 2026-03-25 | 6.3 Medium |
| In LibreChat 0.8.1-rc2, a logged-in user obtains a JWT for both the LibreChat API and the RAG API. | ||||
| CVE-2026-25745 | 2 Open-emr, Openemr | 2 Openemr, Openemr | 2026-03-25 | 6.5 Medium |
| OpenEMR is a free and open source electronic health records and medical practice management application. In versions up to and including 8.0.0, the message/note update endpoint (e.g. PUT or POST) updates by message/note ID only and does not verify that the message belongs to the current patient (or that the user is allowed to edit that patient’s notes). An authenticated user with notes permission can modify any patient’s messages by supplying another message ID. Commit 92a2ff9eaaa80674b3a934a6556e35e7aded5a41 contains a fix for the issue. | ||||
| CVE-2026-32638 | 2 Studiocms, Withstudiocms | 2 Studiocms, Studiocms | 2026-03-25 | 2.7 Low |
| StudioCMS is a server-side-rendered, Astro native, headless content management system. Prior to 0.4.4, the REST API `getUsers` endpoint in StudioCMS uses the attacker-controlled `rank` query parameter to decide whether owner accounts should be filtered from the result set. As a result, an admin token can request `rank=owner` and receive owner account records, including IDs, usernames, display names, and email addresses, even though the adjacent `getUser` endpoint correctly blocks admins from viewing owner users. This is an authorization inconsistency inside the same user-management surface. Version 0.4.4 fixes the issue. | ||||
| CVE-2026-32944 | 2 Parse Community, Parseplatform | 2 Parse Server, Parse-server | 2026-03-25 | 7.5 High |
| Parse Server is an open source backend that can be deployed to any infrastructure that can run Node.js. Prior to 9.6.0-alpha.21 and 8.6.45, an unauthenticated attacker can crash the Parse Server process by sending a single request with deeply nested query condition operators. This terminates the server and denies service to all connected clients. Starting in version 9.6.0-alpha.21 and 8.6.45, a depth limit for query condition operator nesting has been added via the `requestComplexity.queryDepth` server option. The option is disabled by default to avoid a breaking change. To mitigate, upgrade and set the option to a value appropriate for your app. No known workarounds are available. | ||||
| CVE-2025-41660 | 1 Codesys | 16 Codesys Hmi (sl), Control For Beaglebone Sl, Control For Empc-a/imx6 Sl and 13 more | 2026-03-25 | 8.8 High |
| A low-privileged remote attacker may be able to replace the boot application of the CODESYS Control runtime system, enabling unauthorized code execution. | ||||
| CVE-2026-33484 | 1 Langflow | 1 Langflow | 2026-03-25 | 7.5 High |
| Langflow is a tool for building and deploying AI-powered agents and workflows. In versions 1.0.0 through 1.8.1, the `/api/v1/files/images/{flow_id}/{file_name}` endpoint serves image files without any authentication or ownership check. Any unauthenticated request with a known flow_id and file_name returns the image with HTTP 200. In a multi-tenant deployment, any attacker who can discover or guess a `flow_id` (UUIDs can be leaked through other API responses) can download any user's uploaded images without credentials. Version 1.9.0 contains a patch. | ||||
| CVE-2026-33313 | 2 Go-vikunja, Vikunja | 2 Vikunja, Vikunja | 2026-03-25 | 4.3 Medium |
| Vikunja is an open-source self-hosted task management platform. Prior to version 2.2.0, an authenticated user can read any task comment by ID, regardless of whether they have access to the task the comment belongs to, by substituting the task ID in the API URL with a task they do have access to. Version 2.2.0 fixes the issue. | ||||
| CVE-2026-23157 | 1 Linux | 1 Linux Kernel | 2026-03-25 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: btrfs: do not strictly require dirty metadata threshold for metadata writepages [BUG] There is an internal report that over 1000 processes are waiting at the io_schedule_timeout() of balance_dirty_pages(), causing a system hang and trigger a kernel coredump. The kernel is v6.4 kernel based, but the root problem still applies to any upstream kernel before v6.18. [CAUSE] From Jan Kara for his wisdom on the dirty page balance behavior first. This cgroup dirty limit was what was actually playing the role here because the cgroup had only a small amount of memory and so the dirty limit for it was something like 16MB. Dirty throttling is responsible for enforcing that nobody can dirty (significantly) more dirty memory than there's dirty limit. Thus when a task is dirtying pages it periodically enters into balance_dirty_pages() and we let it sleep there to slow down the dirtying. When the system is over dirty limit already (either globally or within a cgroup of the running task), we will not let the task exit from balance_dirty_pages() until the number of dirty pages drops below the limit. So in this particular case, as I already mentioned, there was a cgroup with relatively small amount of memory and as a result with dirty limit set at 16MB. A task from that cgroup has dirtied about 28MB worth of pages in btrfs btree inode and these were practically the only dirty pages in that cgroup. So that means the only way to reduce the dirty pages of that cgroup is to writeback the dirty pages of btrfs btree inode, and only after that those processes can exit balance_dirty_pages(). Now back to the btrfs part, btree_writepages() is responsible for writing back dirty btree inode pages. The problem here is, there is a btrfs internal threshold that if the btree inode's dirty bytes are below the 32M threshold, it will not do any writeback. This behavior is to batch as much metadata as possible so we won't write back those tree blocks and then later re-COW them again for another modification. This internal 32MiB is higher than the existing dirty page size (28MiB), meaning no writeback will happen, causing a deadlock between btrfs and cgroup: - Btrfs doesn't want to write back btree inode until more dirty pages - Cgroup/MM doesn't want more dirty pages for btrfs btree inode Thus any process touching that btree inode is put into sleep until the number of dirty pages is reduced. Thanks Jan Kara a lot for the analysis of the root cause. [ENHANCEMENT] Since kernel commit b55102826d7d ("btrfs: set AS_KERNEL_FILE on the btree_inode"), btrfs btree inode pages will only be charged to the root cgroup which should have a much larger limit than btrfs' 32MiB threshold. So it should not affect newer kernels. But for all current LTS kernels, they are all affected by this problem, and backporting the whole AS_KERNEL_FILE may not be a good idea. Even for newer kernels I still think it's a good idea to get rid of the internal threshold at btree_writepages(), since for most cases cgroup/MM has a better view of full system memory usage than btrfs' fixed threshold. For internal callers using btrfs_btree_balance_dirty() since that function is already doing internal threshold check, we don't need to bother them. But for external callers of btree_writepages(), just respect their requests and write back whatever they want, ignoring the internal btrfs threshold to avoid such deadlock on btree inode dirty page balancing. | ||||
| CVE-2026-23066 | 1 Linux | 1 Linux Kernel | 2026-03-25 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: rxrpc: Fix recvmsg() unconditional requeue If rxrpc_recvmsg() fails because MSG_DONTWAIT was specified but the call at the front of the recvmsg queue already has its mutex locked, it requeues the call - whether or not the call is already queued. The call may be on the queue because MSG_PEEK was also passed and so the call was not dequeued or because the I/O thread requeued it. The unconditional requeue may then corrupt the recvmsg queue, leading to things like UAFs or refcount underruns. Fix this by only requeuing the call if it isn't already on the queue - and moving it to the front if it is already queued. If we don't queue it, we have to put the ref we obtained by dequeuing it. Also, MSG_PEEK doesn't dequeue the call so shouldn't call rxrpc_notify_socket() for the call if we didn't use up all the data on the queue, so fix that also. | ||||
| CVE-2024-56719 | 1 Linux | 1 Linux Kernel | 2026-03-25 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: net: stmmac: fix TSO DMA API usage causing oops Commit 66600fac7a98 ("net: stmmac: TSO: Fix unbalanced DMA map/unmap for non-paged SKB data") moved the assignment of tx_skbuff_dma[]'s members to be later in stmmac_tso_xmit(). The buf (dma cookie) and len stored in this structure are passed to dma_unmap_single() by stmmac_tx_clean(). The DMA API requires that the dma cookie passed to dma_unmap_single() is the same as the value returned from dma_map_single(). However, by moving the assignment later, this is not the case when priv->dma_cap.addr64 > 32 as "des" is offset by proto_hdr_len. This causes problems such as: dwc-eth-dwmac 2490000.ethernet eth0: Tx DMA map failed and with DMA_API_DEBUG enabled: DMA-API: dwc-eth-dwmac 2490000.ethernet: device driver tries to +free DMA memory it has not allocated [device address=0x000000ffffcf65c0] [size=66 bytes] Fix this by maintaining "des" as the original DMA cookie, and use tso_des to pass the offset DMA cookie to stmmac_tso_allocator(). Full details of the crashes can be found at: https://lore.kernel.org/all/d8112193-0386-4e14-b516-37c2d838171a@nvidia.com/ https://lore.kernel.org/all/klkzp5yn5kq5efgtrow6wbvnc46bcqfxs65nz3qy77ujr5turc@bwwhelz2l4dw/ | ||||
| CVE-2026-32300 | 1 Opensource-workshop | 1 Connect-cms | 2026-03-24 | 8.1 High |
| Connect-CMS is a content management system. In versions on the 1.x series up to and including 1.41.0 and versions on the 2.x series up to and including 2.41.0, an improper authorization issue in the My Page profile update feature may allow modification of arbitrary user information. Versions 1.41.1 and 2.41.1 contain a patch. | ||||
| CVE-2026-23487 | 2 Blinko, Blinkospace | 2 Blinko, Blinko | 2026-03-24 | 6.5 Medium |
| Blinko is an AI-powered card note-taking project. Prior to version 1.8.4, there is an IDOR vulnerability where user.detail Endpoint Leaks the Superadmin Token. This issue has been patched in version 1.8.4. | ||||
| CVE-2026-26209 | 1 Agronholm | 1 Cbor2 | 2026-03-24 | 5.5 Medium |
| cbor2 provides encoding and decoding for the Concise Binary Object Representation (CBOR) serialization format. Versions prior to 5.9.0 are vulnerable to a Denial of Service (DoS) attack caused by uncontrolled recursion when decoding deeply nested CBOR structures. This vulnerability affects both the pure Python implementation and the C extension `_cbor2`. The C extension relies on Python's internal recursion limits `Py_EnterRecursiveCall` rather than a data-driven depth limit, meaning it still raises `RecursionError` and crashes the worker process when the limit is hit. While the library handles moderate nesting levels, it lacks a hard depth limit. An attacker can supply a crafted CBOR payload containing approximately 100,000 nested arrays `0x81`. When `cbor2.loads()` attempts to parse this, it hits the Python interpreter's maximum recursion depth or exhausts the stack, causing the process to crash with a `RecursionError`. Because the library does not enforce its own limits, it allows an external attacker to exhaust the host application's stack resource. In many web application servers (e.g., Gunicorn, Uvicorn) or task queues (Celery), an unhandled `RecursionError` terminates the worker process immediately. By sending a stream of these small (<100KB) malicious packets, an attacker can repeatedly crash worker processes, resulting in a complete Denial of Service for the application. Version 5.9.0 patches the issue. | ||||