CVE-2024-5389 is a High severity (CVSS 8.1) access control flaw in lunary-ai/lunary version 1.2.13. Logged-in users can create, read, update and delete prompt variations on datasets that belong to other organizations. The record names no fixed version, so check the project's releases and the advisory before you rely on any upgrade.
What's affected
- Product: Lunary, the open source LLM observability and prompt management project (lunary-ai/lunary).
- Affected version: 1.2.13, which is the only version the record lists.
- Fixed version: not stated in the record. The disclosure page on huntr would not load without JavaScript when I tried it, so I could not confirm one. Treat any fixed version you see quoted elsewhere as unconfirmed until you read the project's release notes.
- Severity: High, CVSS 8.1. The vector needs a low privilege account (PR:L) and no user interaction, and it rates confidentiality and integrity impact as high with no availability impact.
- Exploitation: the record's KEV flag is false, and no advisory I read says it is exploited in the wild.
How to check if you're exposed
Only self-hosted deployments of Lunary are in scope for a version check. Look at the version of the container image or the checked out release you run. If it is 1.2.13, assume you are affected.
Then ask a practical question: do you run more than one organization or project on the same instance? The record describes the flaw as a missing ownership check between the requesting user's organization or project and the dataset prompt being touched. A single-tenant install with trusted users has far less exposure than a shared one.
If you build Lunary from source, your lockfile or image tag tells you the release. A dependency scan of the repository that ships it will also list the version. You can run the free in-browser scan at gold.safeguard.sh/scan against a manifest to see whether the package shows up in your own projects.
What to do now
- Find every Lunary instance in your organization, including test and staging copies, and record its version.
- Open the Lunary releases page and the advisory linked from the record, and note the first release that fixes dataset prompt authorization.
- Upgrade to that release. If you cannot confirm one, ask the maintainers before assuming a newer version is safe.
- Until then, restrict who has accounts on shared instances and remove users who do not need dataset access.
- Review your datasets and prompt variations for unexpected changes or deletions, since the record says unauthorized edits and removals are the outcome.
- Rerun any experiment whose results depended on a dataset that might have been altered.
Why it matters
The record classifies this as CWE-1220, insufficient granularity of access control. The application checks that you are signed in, but not that the object you are asking for belongs to your organization. That gap lets one tenant act on another tenant's data by supplying the right identifier.
The impact here is quiet. Nothing crashes. A prompt variation changes or disappears, and the next evaluation run produces different numbers. The record says this affects the integrity and consistency of dataset information and can skew experiment results, which is a problem for teams who use those results to decide which prompt or model ships.
Quick check
Is CVE-2024-5389 exploited in the wild?
The record sets the KEV flag to false and no advisory I read reports exploitation. Check the CISA Known Exploited Vulnerabilities catalog for changes.
Do I need to worry if only my own team uses the instance?
Much less. The flaw crosses organization boundaries, so the risk grows with the number of separate tenants. Keep the version current anyway.
Sources
- NVD record data for CVE-2024-5389, as supplied in the batch record
- huntr bounty page linked from the record (did not render without JavaScript, so its contents are not used here)
Last reviewed: 19 October 2026.
