Filtered by vendor Lunary
Subscriptions
Total
41 CVE
| CVE | Vendors | Products | Updated | CVSS v3.1 |
|---|---|---|---|---|
| CVE-2024-4154 | 2 Lunary, Lunary-ai | 2 Lunary, Lunary | 2025-01-31 | 6.5 Medium |
| In lunary-ai/lunary version 1.2.2, an incorrect synchronization vulnerability allows unprivileged users to rename projects they do not have access to. Specifically, an unprivileged user can send a PATCH request to the project's endpoint with a new name for a project, despite not having the necessary permissions or being assigned to the project. This issue allows for unauthorized modification of project names, potentially leading to confusion or unauthorized access to project resources. | ||||
| CVE-2024-4151 | 1 Lunary | 1 Lunary | 2025-01-31 | 8.1 High |
| An Improper Access Control vulnerability exists in lunary-ai/lunary version 1.2.2, where users can view and update any prompts in any projects due to insufficient access control checks in the handling of PATCH and GET requests for template versions. This vulnerability allows unauthorized users to manipulate or access sensitive project data, potentially leading to data integrity and confidentiality issues. | ||||
| CVE-2024-1741 | 2 Lunary, Lunary-ai | 2 Lunary, Lunary | 2025-01-31 | 9.1 Critical |
| lunary-ai/lunary version 1.0.1 is vulnerable to improper authorization, allowing removed members to read, create, modify, and delete prompt templates using an old authorization token. Despite being removed from an organization, these members can still perform operations on prompt templates by sending HTTP requests with their previously captured authorization token. This issue exposes organizations to unauthorized access and manipulation of sensitive template data. | ||||
| CVE-2024-1626 | 2 Lunary, Lunary-ai | 2 Lunary, Lunary | 2025-01-31 | 8.1 High |
| An Insecure Direct Object Reference (IDOR) vulnerability exists in the lunary-ai/lunary repository, version 0.3.0, within the project update endpoint. The vulnerability allows authenticated users to modify the name of any project within the system without proper authorization checks, by directly referencing the project's ID in the PATCH request to the '/v1/projects/:projectId' endpoint. This issue arises because the endpoint does not verify if the provided project ID belongs to the currently authenticated user, enabling unauthorized modifications across different organizational projects. | ||||
| CVE-2024-4148 | 2 Lunary, Lunary-ai | 2 Lunary, Lunary | 2025-01-30 | 7.5 High |
| A Regular Expression Denial of Service (ReDoS) vulnerability exists in the lunary-ai/lunary application, version 1.2.10. An attacker can exploit this vulnerability by maliciously manipulating regular expressions, which can significantly impact the response time of the application and potentially render it completely non-functional. Specifically, the vulnerability can be triggered by sending a specially crafted request to the application, leading to a denial of service where the application crashes. | ||||
| CVE-2024-3502 | 2 Lunary, Lunary-ai | 2 Lunary, Lunary-ai\/lunary | 2025-01-30 | 9.1 Critical |
| In lunary-ai/lunary versions up to and including 1.2.5, an information disclosure vulnerability exists where account recovery hashes of users are inadvertently exposed to unauthorized actors. This issue occurs when authenticated users inspect responses from `GET /v1/users/me` and `GET /v1/users/me/org` endpoints. The exposed account recovery hashes, while not directly related to user passwords, represent sensitive information that should not be accessible to unauthorized parties. Exposing these hashes could potentially facilitate account recovery attacks or other malicious activities. The vulnerability was addressed in version 1.2.6. | ||||
| CVE-2024-3501 | 2 Lunary, Lunary-ai | 2 Lunary, Lunary-ai\/lunary | 2025-01-30 | 9.1 Critical |
| In lunary-ai/lunary versions up to and including 1.2.5, an information disclosure vulnerability exists due to the inclusion of single-use tokens in the responses of `GET /v1/users/me` and `GET /v1/users/me/org` API endpoints. These tokens, intended for sensitive operations such as password resets or account verification, are exposed to unauthorized actors, potentially allowing them to perform actions on behalf of the user. This issue was addressed in version 1.2.6, where the exposure of single-use tokens in user-facing queries was mitigated. | ||||
| CVE-2024-1625 | 2 Lunary, Lunary-ai | 2 Lunary, Lunary | 2025-01-30 | 6.5 Medium |
| An Insecure Direct Object Reference (IDOR) vulnerability exists in the lunary-ai/lunary application version 0.3.0, allowing unauthorized deletion of any organization's project. The vulnerability is due to insufficient authorization checks in the project deletion endpoint, where the endpoint fails to verify if the project ID provided in the request belongs to the requesting user's organization. As a result, an attacker can delete projects belonging to any organization by sending a crafted DELETE request with the target project's ID. This issue affects the project deletion functionality implemented in the projects.delete route. | ||||
| CVE-2024-3761 | 1 Lunary | 1 Lunary | 2025-01-10 | 7.5 High |
| In lunary-ai/lunary version 1.2.2, the DELETE endpoint located at `packages/backend/src/api/v1/datasets` is vulnerable to unauthorized dataset deletion due to missing authorization and authentication mechanisms. This vulnerability allows any user, even those without a valid token, to delete a dataset by sending a DELETE request to the endpoint. The issue was fixed in version 1.2.8. The impact of this vulnerability is significant as it permits unauthorized users to delete datasets, potentially leading to data loss or disruption of service. | ||||
| CVE-2024-1738 | 1 Lunary | 1 Lunary | 2025-01-10 | 7.5 High |
| An incorrect authorization vulnerability exists in the lunary-ai/lunary repository, specifically within the evaluations.get route in the evaluations API endpoint. This vulnerability allows unauthorized users to retrieve the results of any organization's evaluation by simply knowing the evaluation ID, due to the lack of project ID verification in the SQL query. As a result, attackers can gain access to potentially private data contained within the evaluation results. | ||||
| CVE-2024-1666 | 1 Lunary | 1 Lunary | 2025-01-10 | 5.3 Medium |
| In lunary-ai/lunary version 1.0.0, an authorization flaw exists that allows unauthorized radar creation. The vulnerability stems from the lack of server-side checks to verify if a user is on a free account during the radar creation process, which is only enforced in the web UI. As a result, attackers can bypass the intended account upgrade requirement by directly sending crafted requests to the server, enabling the creation of an unlimited number of radars without payment. | ||||
| CVE-2024-1902 | 1 Lunary | 1 Lunary | 2025-01-10 | 7.5 High |
| lunary-ai/lunary is vulnerable to a session reuse attack, allowing a removed user to change the organization name without proper authorization. The vulnerability stems from the lack of validation to check if a user is still part of an organization before allowing them to make changes. An attacker can exploit this by using an old authorization token to send a PATCH request, modifying the organization's name even after being removed from the organization. This issue is due to incorrect synchronization and affects the orgs.patch route. | ||||
| CVE-2024-1740 | 1 Lunary | 1 Lunary | 2025-01-10 | 9.1 Critical |
| In lunary-ai/lunary version 1.0.1, a vulnerability exists where a user removed from an organization can still read, create, modify, and delete logs by re-using an old authorization token. The lunary web application communicates with the server using an 'Authorization' token in the browser, which does not properly invalidate upon the user's removal from the organization. This allows the removed user to perform unauthorized actions on logs and access project and external user details without valid permissions. | ||||
| CVE-2024-7474 | 2 Lunary, Lunary-ai | 2 Lunary, Lunary | 2025-01-09 | 8.1 High |
| In version 1.3.2 of lunary-ai/lunary, an Insecure Direct Object Reference (IDOR) vulnerability exists. A user can view or delete external users by manipulating the 'id' parameter in the request URL. The application does not perform adequate checks on the 'id' parameter, allowing unauthorized access to external user data. | ||||
| CVE-2024-6086 | 1 Lunary | 1 Lunary | 2024-11-21 | 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-5755 | 1 Lunary | 1 Lunary | 2024-11-21 | 5.3 Medium |
| In lunary-ai/lunary versions <=v1.2.11, an attacker can bypass email validation by using a dot character ('.') in the email address. This allows the creation of multiple accounts with essentially the same email address (e.g., 'attacker123@gmail.com' and 'attacker.123@gmail.com'), leading to incorrect synchronization and potential security issues. | ||||
| CVE-2024-5714 | 1 Lunary | 1 Lunary | 2024-11-21 | 6.8 Medium |
| In lunary-ai/lunary version 1.2.4, an improper access control vulnerability allows members with team management permissions to manipulate project identifiers in requests, enabling them to invite users to projects in other organizations, change members to projects in other organizations with escalated privileges, and change members from other organizations to their own or other projects, also with escalated privileges. This vulnerability is due to the backend's failure to validate project identifiers against the current user's organization ID and projects belonging to it, as well as a misconfiguration in attribute naming (`org_id` should be `orgId`) that prevents proper user organization validation. As a result, attackers can cause inconsistencies on the platform for affected users and organizations, including unauthorized privilege escalation. The issue is present in the backend API endpoints for user invitation and modification, specifically in the handling of project IDs in requests. | ||||
| CVE-2024-5478 | 1 Lunary | 1 Lunary | 2024-11-21 | 6.1 Medium |
| A Cross-site Scripting (XSS) vulnerability exists in the SAML metadata endpoint `/auth/saml/${org?.id}/metadata` of lunary-ai/lunary version 1.2.7. The vulnerability arises due to the application's failure to escape or validate the `orgId` parameter supplied by the user before incorporating it into the generated response. Specifically, the endpoint generates XML responses for SAML metadata, where the `orgId` parameter is directly embedded into the XML structure without proper sanitization or validation. This flaw allows an attacker to inject arbitrary JavaScript code into the generated SAML metadata page, leading to potential theft of user cookies or authentication tokens. | ||||
| CVE-2024-5389 | 1 Lunary | 1 Lunary | 2024-11-21 | 8.1 High |
| In lunary-ai/lunary version 1.2.13, an insufficient granularity of access control vulnerability allows users to create, update, get, and delete prompt variations for datasets not owned by their organization. This issue arises due to the application not properly validating the ownership of dataset prompts and their variations against the organization or project of the requesting user. As a result, unauthorized modifications to dataset prompts can occur, leading to altered or removed dataset prompts without proper authorization. This vulnerability impacts the integrity and consistency of dataset information, potentially affecting the results of experiments. | ||||
| CVE-2024-5328 | 1 Lunary | 1 Lunary | 2024-11-21 | 9.3 Critical |
| A Server-Side Request Forgery (SSRF) vulnerability exists in the lunary-ai/lunary application, specifically within the endpoint '/auth/saml/tto/download-idp-xml'. The vulnerability arises due to the application's failure to validate user-supplied URLs before using them in server-side requests. An attacker can exploit this vulnerability by sending a specially crafted request to the affected endpoint, allowing them to make unauthorized requests to internal or external resources. This could lead to the disclosure of sensitive information, service disruption, or further attacks against the network infrastructure. The issue affects the latest version of the application as of the report. | ||||