CVE-2024-3379: High Authorization Flaw in lunary

CVE-2024-3379 is a high severity (CVSS 8.1) incorrect authorization flaw in lunary-ai/lunary versions 1.2.2 through 1.2.6. A Member role user can regenerate the private key of a project they have no access to. The record says it was fixed in version 1.2.7, so upgrade to 1.2.7 or later.

What's affected

The record says lunary-ai/lunary versions 1.2.2 through 1.2.6 are affected and that the issue was fixed in version 1.2.7. Lunary is an open source observability and prompt management platform for applications built on large language models. The flaw lets a user with the Member role send a request that regenerates the private key of a project, without the permission or an assignment to that project.

The weakness is CWE-863, incorrect authorization. The NVD vector is CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:N. A low privilege account is needed, and the impact on confidentiality and integrity is high, which gives 8.1.

The references are a GitHub commit in the lunary repository and a huntr bounty report. I could not load either page in this review, so the details come from the record. The record was published on 14 November 2024. It is not marked as exploited in the wild and is not in the CISA KEV list.

How to check if you're exposed

1. Find out whether you self host Lunary. The hosted service is run by the vendor, so this applies to your own deployments.
2. Check the version. For a Docker deployment, look at the image tag you run. For a source checkout, run git describe and read the result.
3. If the version is between 1.2.2 and 1.2.6, you are in scope.
4. List the users who hold the Member role and the projects they belong to. Any such user could reach projects outside their own in an affected version.
5. Look in the application logs or database for private key regeneration events on projects where the actor was not assigned.

What to do now

1. Upgrade to 1.2.7 or later, as stated in the record.
2. After upgrading, regenerate the private keys of projects where you cannot rule out misuse, then update every service that uses them.
3. Review which users hold Member access and remove accounts you do not recognize.
4. Check data in your projects for traces and prompts you did not expect to see written.
5. Limit public sign up on a self hosted instance if you do not need it, since an easy way to get a Member account makes the flaw simpler to abuse.

Why it matters

A private key in Lunary is what lets an application send events to a project. Regenerating it is not only a nuisance. It can lock the real owner out of their integrations and give control of the new key to whoever requested it. The record rates confidentiality and integrity impact as high for this reason.

The cause is a missing check. The endpoint confirmed that the caller was signed in, but did not confirm that the caller belonged to the project. This pattern is called a broken object level authorization, and it is common in APIs that pass identifiers in requests. The fix is to check ownership on every request, on the server, for every object.

Quick check

Sources

• NVD record for CVE-2024-3379
• Fix commit in lunary-ai/lunary (referenced by the record)
• huntr bounty report (referenced by the record)

Last reviewed: 19 October 2026.