Filtered by vendor Lunary-ai
Subscriptions
Total
30 CVE
| CVE | Vendors | Products | Updated | CVSS v3.1 |
|---|---|---|---|---|
| CVE-2024-5386 | 1 Lunary-ai | 1 Lunary | 2026-02-04 | N/A |
| 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-4147 | 1 Lunary-ai | 1 Lunary | 2026-02-04 | N/A |
| In lunary-ai/lunary version 1.2.13, an insufficient granularity of access control vulnerability allows users to delete prompts created in other organizations through ID manipulation. The vulnerability stems from the application's failure to validate the ownership of the prompt before deletion, only checking if the user has permissions to delete such resources without verifying if it belongs to the user's project or organization. As a result, users can remove prompts not owned by their organization or project, leading to legitimate users being unable to access the removed prompts and causing information inconsistencies. | ||||
| CVE-2025-9803 | 2 Lunary, Lunary-ai | 2 Lunary, Lunary | 2025-12-30 | 8.8 High |
| lunary-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-2025-4779 | 2 Lunary, Lunary-ai | 2 Lunary, Lunary | 2025-12-03 | 6.1 Medium |
| lunary-ai/lunary versions prior to 1.9.24 are vulnerable to stored cross-site scripting (XSS). An unauthenticated attacker can inject malicious JavaScript into the `v1/runs/ingest` endpoint by adding an empty `citations` field, triggering a code path where `dangerouslySetInnerHTML` is used to render attacker-controlled text. This vulnerability allows the execution of arbitrary JavaScript in the context of the user's browser, potentially leading to session hijacking, data theft, or other malicious actions. | ||||
| CVE-2025-5352 | 2 Lunary, Lunary-ai | 2 Lunary, Lunary | 2025-11-26 | 9.6 Critical |
| A 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-7475 | 2 Lunary, Lunary-ai | 2 Lunary, Lunary-ai\/lunary | 2025-10-21 | 9.1 Critical |
| An 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-7472 | 2 Lunary, Lunary-ai | 2 Lunary, Lunary | 2025-10-15 | 6.5 Medium |
| lunary-ai/lunary v1.2.26 contains an email injection vulnerability in the Send email verification API (/v1/users/send-verification) and Sign up API (/auth/signup). An unauthenticated attacker can inject data into outgoing emails by bypassing the extractFirstName function using a different whitespace character (e.g., \xa0). This vulnerability can be exploited to conduct phishing attacks, damage the application's brand, cause legal and compliance issues, and result in financial impact due to unauthorized email usage. | ||||
| CVE-2024-6087 | 2 Lunary, Lunary-ai | 2 Lunary, Lunary-ai\/lunary | 2025-10-15 | 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-5714 | 2 Lunary, Lunary-ai | 2 Lunary, Lunary | 2025-10-15 | 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-5130 | 2 Lunary, Lunary-ai | 2 Lunary, Lunary | 2025-10-15 | 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-3502 | 2 Lunary, Lunary-ai | 2 Lunary, Lunary-ai\/lunary | 2025-10-15 | 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-2025-4962 | 1 Lunary-ai | 1 Lunary | 2025-08-18 | N/A |
| An Insecure Direct Object Reference (IDOR) vulnerability was identified in the `POST /v1/templates` endpoint of the Lunary API, affecting versions up to 0.8.8. This vulnerability allows authenticated users to create templates in another user's project by altering the `projectId` query parameter. The root cause of this issue is the absence of server-side validation to ensure that the authenticated user owns the specified `projectId`. The vulnerability has been addressed in version 1.9.23. | ||||
| CVE-2024-1643 | 1 Lunary-ai | 1 Lunary | 2025-07-13 | N/A |
| By knowing an organization's ID, an attacker can join the organization without permission and gain the ability to read and modify all data within that organization. This vulnerability allows unauthorized access and modification of sensitive information, posing a significant security risk. The flaw is due to insufficient verification of user permissions when joining an organization. | ||||
| 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-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-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-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. | ||||