CVE-2024-4146 is a critical severity incorrect authorization flaw in lunary-ai/lunary version 1.2.13. NVD scores it 9.8. Users in an organization can reach projects they were never granted. Upgrade to a release that includes the upstream fix commit and review project membership.
What's affected
The record lists lunary version 1.2.13. The flaw is in the checkProjectAccess method in the authorization middleware. As the record describes it, the method only checks that a user belongs to the organization that owns a project. It does not check the account_project table for explicit project rights.
The result is that a user could gain control of every resource in a project they should not have been able to see. The vector is CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H. The record links a fix commit in the lunary repository and a huntr bounty report. We did not fetch either, so the first release containing the fix needs to be confirmed in the project release notes.
Weakness class: CWE-863 (incorrect authorization).
How to check if you're exposed
If you self host lunary, read the running version from the image tag or package version:
docker inspect --format "{.Config.Image}" CONTAINER_NAME
Version 1.2.13 is named in the record. Then list your projects and who is assigned to each one. Any user who is part of the organization, but not assigned to a project, could have reached it on an affected build.
What to do now
- Upgrade lunary to a version that includes the fix commit and confirm it in the release notes.
- Review project membership and remove access that is not needed.
- Look in logs and the audit trail for access to projects by users who are not assigned to them.
- Rotate API keys and secrets held in projects that may have been reached by the wrong users.
- Keep the lunary interface off the open internet unless you need it there.
Why it matters
This is an authorization flaw, not an authentication flaw. Users were logged in correctly, but the check on what they could touch was too coarse. It only asked whether the user belonged to the organization, and skipped the finer question of whether the user belongs to this project.
In a tool that stores prompts, logs and keys for language model apps, that gap exposes data and lets a user change it. The score is high on all three impact measures for this reason. The KEV flag is false and the record does not claim exploitation in the wild.
Safeguard has a free in-browser dependency scan at gold.safeguard.sh/scan and a Gold directory of vulnerability pages for software you already track.
Try it yourself
Click through it at your own pace, or open it full screen.
Quick check
Is this authentication bypass?
No. The users are authenticated. The weakness is that project level permissions were not checked.
Which release fixes it?
The record links a fix commit but names no release. Check the project release notes.
Sources
These are the references listed in the record. We did not fetch them for this draft, so the version and fix details above come from the record alone and the advisory should be checked.
Last reviewed: 19 October 2026.
