Lunary
Vulnerabilities
69
Known exploited
0
Max CVSS
9.8
Top EPSS
0.01359
Severity breakdown
Critical
9
High
32
Medium
28
Low
0
Affected version ranges
1.2.2–1.2.251.2.2–1.2.71.2.5–1.4.91.2.7–1.4.3< 1.0.0< 1.0.2< 1.2.14< 1.2.25< 1.2.26< 1.2.4< 1.2.6< 1.2.7< 1.2.8< 1.3.4< 1.4.23< 1.4.26< 1.4.30< 1.4.9< 1.5.7< 1.5.9< 1.6.1< 1.6.3< 1.7.10< 1.9.24
Also matched as (raw): lunary
Top vulnerabilities
CVE-2024-9095In 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-7456A 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-4146In lunary-ai/lunary version v1.2.13, an incorrect authorization vulnerability exists that allows unauthorized users to access and manipulate projects within an organization they should not have access to. Specifically, the vulnerability is located in the `checkProjectAccess` method within the authorization middleware, which fails to adequately verify if a user has the correct permissions to access a specific project. Instead, it only checks if the user is part of the organization owning the project, overlooking the necessary check against the `account_project` table for explicit project access rights. This flaw enables attackers to gain complete control over all resources within a project, including the ability to create, update, read, and delete any resource, compromising the privacy and security of sensitive information.
CVE-2025-5352A critical stored Cross-Site Scripting (XSS) vulnerability exists in the Analytics component of lunary-ai/lunary versions up to 1.9.23, where the NEXT_PUBLIC_CUSTOM_SCRIPT environment variable is directly injected into the DOM using dangerouslySetInnerHTML without any sanitization or validation. This allows arbitrary JavaScript execution in all users' browsers if an attacker can control the environment variable during deployment or through server compromise. The vulnerability can lead to complete account takeover, data exfiltration, malware distribution, and persistent attacks affecting all users until the environment variable is cleaned. The issue is fixed in version 1.9.25.
CVE-2024-5328A 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-7475An improper access control vulnerability in lunary-ai/lunary version 1.3.2 allows an attacker to update the SAML configuration without authorization. This vulnerability can lead to manipulation of authentication processes, fraudulent login requests, and theft of user information. Appropriate access controls should be implemented to ensure that the SAML configuration can only be updated by authorized users.
CVE-2024-1741lunary-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-1740In 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-1739lunary-ai/lunary is vulnerable to an authentication issue due to improper validation of email addresses during the signup process. Specifically, the server fails to treat email addresses as case insensitive, allowing the creation of multiple accounts with the same email address by varying the case of the email characters. For example, accounts for 'abc@gmail.com' and 'Abc@gmail.com' can both be created, leading to potential impersonation and confusion among users.
CVE-2025-9803lunary-ai/lunary version 1.9.34 is vulnerable to an account takeover due to improper authentication in the Google OAuth integration. The application fails to verify the 'aud' (audience) field in the access token issued by Google, which is crucial for ensuring the token is intended for the application. This oversight allows attackers to use tokens issued to malicious applications to gain unauthorized access to user accounts. The issue is resolved in version 1.9.35.
CVE-2024-5386In 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-5128An 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-5129A 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-9099In lunary-ai/lunary version v1.4.29, the GET /projects API endpoint exposes both public and private API keys for all projects to users with minimal permissions, such as Viewers or Prompt Editors. This vulnerability allows unauthorized users to retrieve sensitive credentials, which can be used to perform actions on behalf of the project, access private data, and delete resources. The private API keys are exposed in the developer tools when the endpoint is called from the frontend.
CVE-2024-7474In 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-6862A 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-5389In 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-5133In 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-4151An 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-3502In 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-3501In 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-3379In lunary-ai/lunary versions 1.2.2 through 1.2.6, an incorrect authorization vulnerability allows unprivileged users to re-generate the private key for projects they do not have access to. Specifically, a user with a 'Member' role can issue a request to regenerate the private key of a project without having the necessary permissions or being assigned to that project. This issue was fixed in version 1.2.7.
CVE-2024-1626An 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-10762In lunary-ai/lunary before version 1.5.9, the /v1/evaluators/ endpoint allows users to delete evaluators of a project by sending a DELETE request. However, the route lacks proper access control, such as middleware to ensure that only users with appropriate roles can delete evaluator data. This vulnerability allows low-privilege users to delete evaluators data, causing permanent data loss and potentially hindering operations.
CVE-2024-8999lunary-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.