Filtered by vendor Lunary
Subscribe
Total
69 CVE
| CVE | Vendors | Products | Updated | CVSS v2 | CVSS v3 |
|---|---|---|---|---|---|
| CVE-2024-7456 | 1 Lunary | 1 Lunary | 2026-06-17 | N/A | 9.8 CRITICAL |
| A SQL injection vulnerability exists in the `/api/v1/external-users` route of lunary-ai/lunary version v1.4.2. The `order by` clause of the SQL query uses `sql.unsafe` without prior sanitization, allowing for SQL injection. The `orderByClause` variable is constructed without server-side validation or sanitization, enabling an attacker to execute arbitrary SQL commands. Successful exploitation can lead to complete data loss, modification, or corruption. | |||||
| CVE-2024-6867 | 1 Lunary | 1 Lunary | 2026-06-17 | N/A | 6.5 MEDIUM |
| An information disclosure vulnerability exists in the lunary-ai/lunary, specifically in the `runs/{run_id}/related` endpoint. This endpoint does not verify that the user has the necessary access rights to the run(s) they are accessing. As a result, it returns not only the specified run but also all runs that have the `run_id` listed as their parent run. This issue affects the main branch, commit a761d833. The vulnerability allows unauthorized users to obtain information about non-public runs and their related runs, given the `run_id` of a public or non-public run. | |||||
| CVE-2024-6862 | 1 Lunary | 1 Lunary | 2026-06-17 | N/A | 8.1 HIGH |
| A Cross-Site Request Forgery (CSRF) vulnerability exists in lunary-ai/lunary version 1.2.34 due to overly permissive CORS settings. This vulnerability allows an attacker to sign up for and create projects or use the instance as if they were a user with local access. The main attack vector is for instances hosted locally on personal machines, which are not publicly accessible. The CORS settings in the backend permit all origins, exposing unauthenticated endpoints to CSRF attacks. | |||||
| CVE-2024-6582 | 1 Lunary | 1 Lunary | 2026-06-17 | N/A | 4.3 MEDIUM |
| A broken access control vulnerability exists in the latest version of lunary-ai/lunary. The `saml.ts` file allows a user from one organization to update the Identity Provider (IDP) settings and view the SSO metadata of another organization. This vulnerability can lead to unauthorized access and potential account takeover if the email of a user in the target organization is known. | |||||
| CVE-2024-6087 | 1 Lunary | 1 Lunary | 2026-06-17 | N/A | 6.5 MEDIUM |
| An improper access control vulnerability exists in lunary-ai/lunary at the latest commit (a761d83) on the main branch. The vulnerability allows an attacker to use the auth tokens issued by the 'invite user' functionality to obtain valid JWT tokens. These tokens can be used to compromise target users upon registration for their own arbitrary organizations. The attacker can invite a target email, obtain a one-time use token, retract the invite, and later use the token to reset the password of the target user, leading to full account takeover. | |||||
| CVE-2024-6086 | 1 Lunary | 1 Lunary | 2026-06-17 | N/A | 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 | 2026-06-17 | N/A | 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 | 2026-06-17 | N/A | 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 | 2026-06-17 | N/A | 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 | 2026-06-17 | N/A | 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-5386 | 1 Lunary | 1 Lunary | 2026-06-17 | N/A | 8.8 HIGH |
| In lunary-ai/lunary version 1.2.2, an account hijacking vulnerability exists due to a password reset token leak. A user with a 'viewer' role can exploit this vulnerability to hijack another user's account by obtaining the password reset token. The vulnerability is triggered when the 'viewer' role user sends a specific request to the server, which responds with a password reset token in the 'recoveryToken' parameter. This token can then be used to reset the password of another user's account without authorization. The issue results from an excessive attack surface, allowing lower-privileged users to escalate their privileges and take over accounts. | |||||
| CVE-2024-5328 | 1 Lunary | 1 Lunary | 2026-06-17 | N/A | 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. | |||||
| CVE-2024-5277 | 1 Lunary | 1 Lunary | 2026-06-17 | N/A | 7.5 HIGH |
| In lunary-ai/lunary version 1.2.4, a vulnerability exists in the password recovery mechanism where the reset password token is not invalidated after use. This allows an attacker who compromises the recovery token to repeatedly change the password of a victim's account. The issue lies in the backend's handling of the reset password process, where the token, once used, is not discarded or invalidated, enabling its reuse. This vulnerability could lead to unauthorized account access if an attacker obtains the recovery token. | |||||
| CVE-2024-5248 | 1 Lunary | 1 Lunary | 2026-06-17 | N/A | 6.5 MEDIUM |
| In lunary-ai/lunary version 1.2.5, an improper access control vulnerability exists due to a missing permission check in the `GET /v1/users/me/org` endpoint. The platform's role definitions restrict the `Prompt Editor` role to prompt management and project viewing/listing capabilities, explicitly excluding access to user information. However, the endpoint fails to enforce this restriction, allowing users with the `Prompt Editor` role to access the full list of users in the organization. This vulnerability allows unauthorized access to sensitive user information, violating the intended access controls. | |||||
| CVE-2024-5133 | 1 Lunary | 1 Lunary | 2026-06-17 | N/A | 8.1 HIGH |
| In lunary-ai/lunary version 1.2.4, an account takeover vulnerability exists due to the exposure of password recovery tokens in API responses. Specifically, when a user initiates the password reset process, the recovery token is included in the response of the `GET /v1/users/me/org` endpoint, which lists all users in a team. This allows any authenticated user to capture the recovery token of another user and subsequently change that user's password without consent, effectively taking over the account. The issue lies in the inclusion of the `recovery_token` attribute in the users object returned by the API. | |||||
| CVE-2024-5131 | 1 Lunary | 1 Lunary | 2026-06-17 | N/A | 6.5 MEDIUM |
| An Improper Access Control vulnerability exists in the lunary-ai/lunary repository, affecting versions up to and including 1.2.2. The vulnerability allows unauthorized users to view any prompts in any projects by supplying a specific prompt ID to an endpoint that does not adequately verify the ownership of the prompt ID. This issue was fixed in version 1.2.25. | |||||
| CVE-2024-5130 | 1 Lunary | 1 Lunary | 2026-06-17 | N/A | 7.5 HIGH |
| An Incorrect Authorization vulnerability exists in lunary-ai/lunary versions up to and including 1.2.2, which allows unauthenticated users to delete any dataset. The vulnerability is due to the lack of proper authorization checks in the dataset deletion endpoint. Specifically, the endpoint does not verify if the provided project ID belongs to the current user, thereby allowing any dataset to be deleted without proper authentication. This issue was fixed in version 1.2.8. | |||||
| CVE-2024-5129 | 1 Lunary | 1 Lunary | 2026-06-17 | N/A | 8.2 HIGH |
| A Privilege Escalation Vulnerability exists in lunary-ai/lunary version 1.2.2, where any user can delete any datasets due to missing authorization checks. The vulnerability is present in the dataset deletion functionality, where the application fails to verify if the user requesting the deletion has the appropriate permissions. This allows unauthorized users to send a DELETE request to the server and delete any dataset by specifying its ID. The issue is located in the datasets.delete function within the datasets index file. | |||||
| CVE-2024-5128 | 1 Lunary | 1 Lunary | 2026-06-17 | N/A | 8.8 HIGH |
| An Insecure Direct Object Reference (IDOR) vulnerability was identified in lunary-ai/lunary, affecting versions up to and including 1.2.2. This vulnerability allows unauthorized users to view, update, or delete any dataset_prompt or dataset_prompt_variation within any dataset or project. The issue stems from improper access control checks in the dataset management endpoints, where direct references to object IDs are not adequately secured against unauthorized access. This vulnerability was fixed in version 1.2.25. | |||||
| CVE-2024-5127 | 1 Lunary | 1 Lunary | 2026-06-17 | N/A | 5.4 MEDIUM |
| In lunary-ai/lunary versions 1.2.2 through 1.2.25, an improper access control vulnerability allows users on the Free plan to invite other members and assign them any role, including those intended for Paid and Enterprise plans only. This issue arises due to insufficient backend validation of roles and permissions, enabling unauthorized users to join a project and potentially exploit roles and permissions not intended for their use. The vulnerability specifically affects the Team feature, where the backend fails to validate whether a user has paid for a plan before allowing them to send invite links with any role assigned. This could lead to unauthorized access and manipulation of project settings or data. | |||||