A Regular Expression Denial of Service (ReDoS) vulnerability exists in the lunary-ai/lunary repository, specifically in the compileTextTemplate function. The affected version is git be54057. An attacker can exploit this vulnerability by manipulating the regular expression /{{(.*?)}}/g, causing the server to hang indefinitely and become unresponsive to any requests. This is due to the regular expression's susceptibility to second-degree polynomial time complexity, which can be triggered by a large number of braces in the input.
A vulnerability in lunary-ai/lunary, as of commit be54057, allows users to upload and execute arbitrary regular expressions on the server side. This can lead to a Denial of Service (DoS) condition, as certain regular expressions can cause excessive resource consumption, blocking the server from processing other requests.
A broken access control vulnerability exists in lunary-ai/lunary versions 1.2.7 through 1.4.2. The vulnerability allows an authenticated attacker to modify any user's templates by sending a crafted HTTP POST request to the /v1/templates/{id}/versions endpoint. This issue is resolved in version 1.4.3.
In lunary-ai/lunary before version 1.6.3, an improper access control vulnerability exists where a user can access prompt data of another user. This issue affects version 1.6.2 and the main branch. The vulnerability allows unauthorized users to view sensitive prompt data by accessing specific URLs, leading to potential exposure of critical information.
In lunary-ai/lunary before version 1.6.3, the application allows the creation of evaluators without enforcing a unique constraint on the combination of projectId and slug. This allows an attacker to overwrite existing data by submitting a POST request with the same slug as an existing evaluator. The lack of database constraints or application-layer validation to prevent duplicates exposes the application to data integrity issues. This vulnerability can result in corrupted data and potentially malicious actions, impairing the system's functionality.
An Insecure Direct Object Reference (IDOR) vulnerability exists in the `PATCH /v1/runs/:id/score` endpoint of lunary-ai/lunary version 1.6.0. This vulnerability allows an attacker to update the score data of any run by manipulating the id parameter in the request URL, which corresponds to the `runId_score` in the database. The endpoint does not sufficiently validate whether the authenticated user has permission to modify the specified runId, enabling an attacker with a valid account to modify other users' runId scores by specifying different id values. This issue was fixed in version 1.6.1.
In 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.
In version 1.5.5 of lunary-ai/lunary, a vulnerability exists where admins, who do not have direct permissions to access billing resources, can change the permissions of existing users to include billing permissions. This can lead to a privilege escalation scenario where an administrator can manage billing, effectively bypassing the intended role-based access control. Only users with the 'owner' role should be allowed to invite members with billing permissions. This flaw allows admins to circumvent those restrictions, gaining unauthorized access and control over billing information, posing a risk to the organization’s financial resources.
In lunary-ai/lunary version 1.5.6, the `/v1/evaluators/` endpoint lacks proper access control, allowing any user associated with a project to fetch all evaluator data regardless of their role. This vulnerability permits low-privilege users to access potentially sensitive evaluation data.
lunary-ai/lunary is vulnerable to broken access control in the latest version. An attacker can view the content of any dataset without any kind of authorization by sending a GET request to the /v1/datasets endpoint without a valid authorization token.