CVE-2024-5128 Overview
CVE-2024-5128 is an Insecure Direct Object Reference (IDOR) vulnerability in lunary-ai/lunary, an open-source platform for managing large language model (LLM) applications. The flaw affects all versions up to and including 1.2.2. Authenticated users can view, update, or delete any dataset_prompt or dataset_prompt_variation belonging to other datasets or projects. The root cause is missing access control validation in dataset management endpoints that accept direct object identifiers. The maintainers fixed the issue in version 1.2.25.
Critical Impact
Any authenticated user can read, modify, or destroy prompts and prompt variations across every dataset and project hosted on the affected Lunary instance, breaking tenant isolation.
Affected Products
- lunary-ai/lunary versions up to and including 1.2.2
- Self-hosted Lunary deployments exposing dataset management APIs
- Fixed in lunary-ai/lunary version 1.2.25
Discovery Timeline
- 2024-06-06 - CVE-2024-5128 published to NVD
- 2026-06-17 - Last updated in NVD database
Technical Details for CVE-2024-5128
Vulnerability Analysis
The vulnerability is classified under [CWE-639]: Authorization Bypass Through User-Controlled Key. Lunary exposes REST endpoints that operate on dataset_prompt and dataset_prompt_variation records using server-assigned identifiers. The endpoints accept the object ID supplied in the request path or body and perform the requested action without verifying that the authenticated user owns the parent dataset or project.
An authenticated attacker can enumerate or guess object identifiers and issue requests against resources owned by other tenants. The result is unauthorized read, update, or delete access to prompt datasets that drive downstream LLM workflows.
Root Cause
The dataset management handlers trust the client-supplied object ID as the sole locator for the target record. The handlers query the database by primary key but do not join against the requesting user's project membership or ownership rows. As a result, the authorization layer never compares the caller's project scope to the resource's parent project.
Attack Vector
Exploitation requires only a valid Lunary account on the target instance and network access to the API. The attacker authenticates, then sends standard HTTP requests to dataset prompt endpoints while substituting the target id value. No user interaction or elevated privileges are needed.
For technical specifics, see the fix commit and bounty report:
Detection Methods for CVE-2024-5128
Indicators of Compromise
- Unexpected modifications or deletions of dataset_prompt or dataset_prompt_variation records performed by users outside the owning project.
- API access log entries showing a single account interacting with object IDs across multiple project scopes.
- Sudden enumeration patterns against dataset endpoints with sequential or randomized identifiers.
Detection Strategies
- Review Lunary application logs and database audit trails for cross-project access to dataset prompt resources.
- Correlate the authenticated user ID on each dataset prompt request with the project ownership of the targeted record.
- Alert on bulk DELETE or UPDATE actions against dataset_prompt tables originating from a single session.
Monitoring Recommendations
- Forward Lunary API access logs to a centralized log platform and retain them long enough to investigate retroactive abuse.
- Track per-user request rates against dataset endpoints and flag accounts that touch unusually high numbers of distinct object IDs.
- Monitor outbound traffic from Lunary hosts for exfiltration of prompt content following suspicious read activity.
How to Mitigate CVE-2024-5128
Immediate Actions Required
- Upgrade lunary-ai/lunary to version 1.2.25 or later on all self-hosted instances.
- Audit existing dataset_prompt and dataset_prompt_variation records for unauthorized modifications since the deployment of any version at or below 1.2.2.
- Rotate API tokens and reassess account access, removing inactive or unnecessary users.
Patch Information
The maintainers addressed the issue in commit 0755dde, released in version 1.2.25. The patch enforces project ownership checks on dataset prompt and variation endpoints before any read, write, or delete operation proceeds.
Workarounds
- Restrict network access to the Lunary API so only trusted users on trusted networks can authenticate.
- Reduce the number of accounts with access to sensitive datasets until the patched release is deployed.
- Place an authenticating reverse proxy in front of Lunary that enforces additional per-project authorization checks where feasible.
# Upgrade self-hosted Lunary to the patched release
git fetch --tags
git checkout v1.2.25
npm install
npm run build
npm run start
Disclaimer: This content was generated using AI. While we strive for accuracy, please verify critical information with official sources.

