Export limit exceeded: 35583 CVEs match your query. Please refine your search to export 10,000 CVEs or fewer.
Search
Search Results (35583 CVEs found)
| CVE | Vendors | Products | Updated | CVSS v3.1 |
|---|---|---|---|---|
| CVE-2024-57941 | 1 Linux | 1 Linux Kernel | 2025-10-15 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: netfs: Fix the (non-)cancellation of copy when cache is temporarily disabled When the caching for a cookie is temporarily disabled (e.g. due to a DIO write on that file), future copying to the cache for that file is disabled until all fds open on that file are closed. However, if netfslib is using the deprecated PG_private_2 method (such as is currently used by ceph), and decides it wants to copy to the cache, netfs_advance_write() will just bail at the first check seeing that the cache stream is unavailable, and indicate that it dealt with all the content. This means that we have no subrequests to provide notifications to drive the state machine or even to pin the request and the request just gets discarded, leaving the folios with PG_private_2 set. Fix this by jumping directly to cancel the request if the cache is not available. That way, we don't remove mark3 from the folio_queue list and netfs_pgpriv2_cancel() will clean up the folios. This was found by running the generic/013 xfstest against ceph with an active cache and the "-o fsc" option passed to ceph. That would usually hang | ||||
| CVE-2024-57942 | 1 Linux | 1 Linux Kernel | 2025-10-15 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: netfs: Fix ceph copy to cache on write-begin At the end of netfs_unlock_read_folio() in which folios are marked appropriately for copying to the cache (either with by being marked dirty and having their private data set or by having PG_private_2 set) and then unlocked, the folio_queue struct has the entry pointing to the folio cleared. This presents a problem for netfs_pgpriv2_write_to_the_cache(), which is used to write folios marked with PG_private_2 to the cache as it expects to be able to trawl the folio_queue list thereafter to find the relevant folios, leading to a hang. Fix this by not clearing the folio_queue entry if we're going to do the deprecated copy-to-cache. The clearance will be done instead as the folios are written to the cache. This can be reproduced by starting cachefiles, mounting a ceph filesystem with "-o fsc" and writing to it. | ||||
| CVE-2025-21657 | 1 Linux | 1 Linux Kernel | 2025-10-15 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: sched_ext: Replace rq_lock() to raw_spin_rq_lock() in scx_ops_bypass() scx_ops_bypass() iterates all CPUs to re-enqueue all the scx tasks. For each CPU, it acquires a lock using rq_lock() regardless of whether a CPU is offline or the CPU is currently running a task in a higher scheduler class (e.g., deadline). The rq_lock() is supposed to be used for online CPUs, and the use of rq_lock() may trigger an unnecessary warning in rq_pin_lock(). Therefore, replace rq_lock() to raw_spin_rq_lock() in scx_ops_bypass(). Without this change, we observe the following warning: ===== START ===== [ 6.615205] rq->balance_callback && rq->balance_callback != &balance_push_callback [ 6.615208] WARNING: CPU: 2 PID: 0 at kernel/sched/sched.h:1730 __schedule+0x1130/0x1c90 ===== END ===== | ||||
| CVE-2025-21679 | 1 Linux | 1 Linux Kernel | 2025-10-15 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: btrfs: add the missing error handling inside get_canonical_dev_path Inside function get_canonical_dev_path(), we call d_path() to get the final device path. But d_path() can return error, and in that case the next strscpy() call will trigger an invalid memory access. Add back the missing error handling for d_path(). | ||||
| CVE-2025-1451 | 1 Lollms | 1 Lollms Web Ui | 2025-10-15 | 7.5 High |
| A vulnerability in parisneo/lollms-webui v13 arises from the server's handling of multipart boundaries in file uploads. The server does not limit or validate the length of the boundary or the characters appended to it, allowing an attacker to craft requests with excessively long boundaries, leading to resource exhaustion and eventual denial of service (DoS). Despite an attempted patch in commit 483431bb, which blocked hyphen characters from being appended to the multipart boundary, the fix is insufficient. The server remains vulnerable if other characters (e.g., '4', 'a') are used instead of hyphens. This allows attackers to exploit the vulnerability using different characters, causing resource exhaustion and service unavailability. | ||||
| CVE-2025-0453 | 1 Lfprojects | 1 Mlflow | 2025-10-15 | 7.5 High |
| In mlflow/mlflow version 2.17.2, the `/graphql` endpoint is vulnerable to a denial of service attack. An attacker can create large batches of queries that repeatedly request all runs from a given experiment. This can tie up all the workers allocated by MLFlow, rendering the application unable to respond to other requests. This vulnerability is due to uncontrolled resource consumption. | ||||
| CVE-2025-0189 | 1 Aimstack | 1 Aim | 2025-10-15 | 7.5 High |
| In version 3.25.0 of aimhubio/aim, the tracking server is vulnerable to a denial of service attack. The server overrides the maximum size for websocket messages, allowing very large images to be tracked. This causes the server to become unresponsive to other requests while processing the large image, leading to a denial of service condition. | ||||
| CVE-2024-9098 | 1 Lunary | 1 Lunary | 2025-10-15 | 6.1 Medium |
| In lunary-ai/lunary before version 1.4.30, a privilege escalation vulnerability exists where admins can invite new members with billing permissions, thereby gaining unauthorized access to billing resources. This issue arises because the user creation endpoint does not restrict admins from inviting users with billing roles. As a result, admins can circumvent the intended access control, posing a risk to the organization's financial resources. | ||||
| CVE-2024-9096 | 1 Lunary | 1 Lunary | 2025-10-15 | 7.1 High |
| In lunary-ai/lunary version 1.4.28, the /checklists/:id route allows low-privilege users to modify checklists by sending a PATCH request. The route lacks proper access control, such as middleware to ensure that only authorized users (e.g., project owners or admins) can modify checklist data. This vulnerability allows any user associated with the project, regardless of their role, to modify checklists, including changing the slug or data fields, which can lead to tampering with essential project workflows, altering business logic, and introducing errors that undermine integrity. | ||||
| CVE-2024-9095 | 1 Lunary | 1 Lunary | 2025-10-15 | 9.8 Critical |
| In lunary-ai/lunary version v1.4.28, the /bigquery API route lacks proper access control, allowing any logged-in user to create a Datastream to Google BigQuery and export the entire database. This includes sensitive data such as password hashes and secret API keys. The route is protected by a config check (`config.DATA_WAREHOUSE_EXPORTS_ALLOWED`), but it does not verify the user's access level or implement any access control middleware. This vulnerability can lead to the extraction of sensitive data, disruption of services, credential compromise, and service integrity breaches. | ||||
| CVE-2024-9000 | 1 Lunary | 1 Lunary | 2025-10-15 | 6.5 Medium |
| In lunary-ai/lunary before version 1.4.26, the checklists.post() endpoint allows users to create or modify checklists without validating whether the user has proper permissions. This missing access control permits unauthorized users to create checklists, bypassing intended permission checks. Additionally, the endpoint does not validate the uniqueness of the slug field when creating a new checklist, allowing an attacker to spoof existing checklists by reusing the slug of an already-existing checklist. This can lead to significant data integrity issues, as legitimate checklists can be replaced with malicious or altered data. | ||||
| CVE-2024-8999 | 1 Lunary | 1 Lunary | 2025-10-15 | 7.5 High |
| lunary-ai/lunary version v1.4.25 contains an improper access control vulnerability in the POST /api/v1/data-warehouse/bigquery endpoint. This vulnerability allows any user to export the entire database data by creating a stream to Google BigQuery without proper authentication or authorization. The issue is fixed in version 1.4.26. | ||||
| CVE-2024-8984 | 2 Berriai, Litellm | 2 Litellm, Litellm | 2025-10-15 | N/A |
| A Denial of Service (DoS) vulnerability exists in berriai/litellm version v1.44.5. This vulnerability can be exploited by appending characters, such as dashes (-), to the end of a multipart boundary in an HTTP request. The server continuously processes each character, leading to excessive resource consumption and rendering the service unavailable. The issue is unauthenticated and does not require any user interaction, impacting all users of the service. | ||||
| CVE-2024-8966 | 1 Gradio | 1 Video | 2025-10-15 | 7.5 High |
| A vulnerability in the file upload process of gradio-app/gradio version @gradio/[email protected] allows for a Denial of Service (DoS) attack. An attacker can append a large number of characters to the end of a multipart boundary, causing the system to continuously process each character and issue warnings. This can render Gradio inaccessible for extended periods, disrupting services and causing significant downtime. | ||||
| CVE-2024-8789 | 1 Lunary | 1 Lunary | 2025-10-15 | N/A |
| Lunary-ai/lunary version git 105a3f6 is vulnerable to a Regular Expression Denial of Service (ReDoS) attack. The application allows users to upload their own regular expressions, which are then executed on the server side. Certain regular expressions can have exponential runtime complexity relative to the input size, leading to potential denial of service. An attacker can exploit this by submitting a specially crafted regular expression, causing the server to become unresponsive for an arbitrary length of time. | ||||
| CVE-2024-8613 | 1 Gaizhenbiao | 1 Chuanhuchatgpt | 2025-10-15 | 8.8 High |
| A vulnerability in gaizhenbiao/chuanhuchatgpt version 20240802 allows attackers to access, copy, and delete other users' chat histories. This issue arises due to improper handling of session data and lack of access control mechanisms, enabling attackers to view and manipulate chat histories of other users. | ||||
| CVE-2024-6868 | 1 Mudler | 1 Localai | 2025-10-15 | 9.8 Critical |
| mudler/LocalAI version 2.17.1 allows for arbitrary file write due to improper handling of automatic archive extraction. When model configurations specify additional files as archives (e.g., .tar), these archives are automatically extracted after downloading. This behavior can be exploited to perform a 'tarslip' attack, allowing files to be written to arbitrary locations on the server, bypassing checks that normally restrict files to the models directory. This vulnerability can lead to remote code execution (RCE) by overwriting backend assets used by the server. | ||||
| CVE-2024-6090 | 1 Gaizhenbiao | 1 Chuanhuchatgpt | 2025-10-15 | N/A |
| A path traversal vulnerability exists in gaizhenbiao/chuanhuchatgpt version 20240410, allowing any user to delete other users' chat histories. This vulnerability can also be exploited to delete any files ending in `.json` on the target system, leading to a denial of service as users are unable to authenticate. | ||||
| CVE-2024-6086 | 1 Lunary | 1 Lunary | 2025-10-15 | 4.3 Medium |
| In version 1.2.7 of lunary-ai/lunary, any authenticated user, regardless of their role, can change the name of an organization due to improper access control. The function checkAccess() is not implemented, allowing users with the lowest privileges, such as the 'Prompt Editor' role, to modify organization attributes without proper authorization. | ||||
| CVE-2024-6037 | 1 Gaizhenbiao | 1 Chuanhuchatgpt | 2025-10-15 | 9.1 Critical |
| A vulnerability in gaizhenbiao/chuanhuchatgpt version 20240410 allows an attacker to create arbitrary folders at any location on the server, including the root directory (C: dir). This can lead to uncontrolled resource consumption, resulting in resource exhaustion, denial of service (DoS), server unavailability, and potential data loss or corruption. | ||||