CVE-2024-1740 is a critical (CVSS 9.1) authorization flaw in lunary-ai/lunary version 1.0.1. A user removed from an organization can still read, create, modify and delete logs by reusing an old authorization token. Upgrade to a build with the fix and rotate tokens.
What's affected
Lunary is an open source platform for monitoring and managing applications built on large language models. The record references a GitHub fix commit and a huntr bounty report but does not name a first fixed release, so confirm the version in Lunary's release notes.
The record says that in version 1.0.1 the Authorization token used by the web app is not invalidated when a user is removed from an organization. A removed user can keep acting on logs and access project and external user details.
The NVD score and vector are in the record: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N. The weakness is CWE-863 (incorrect authorization).
How to check if you're exposed
If you self host Lunary, check the version you deployed and whether it includes the fix commit.
git merge-base --is-ancestor c57cd50fa0477fd2a2efe60810c0099eebd66f54 HEAD && echo fixed
For container deployments, compare the image tag with the release notes. Look back through recent removals and check whether those users still made API calls afterwards.
What to do now
- Upgrade Lunary to a release that contains the fix commit.
- Review the membership of your organizations and projects, and remove accounts that should not have access.
- Rotate project API keys if a former member might have had access.
- Restrict who can sign up on a self hosted instance.
- Test authorization on every endpoint that takes an object ID.
Why it matters
Removing a person from a team must end their access immediately, not on token expiry. When the server checks only that a token is valid and not that the user is still a member, offboarding does not work. The score is critical because of the scope of data and actions. The record does not flag exploitation. Safeguard's free in-browser dependency scan at gold.safeguard.sh/scan can show whether a component tied to this CVE appears in your dependency manifests. The Gold directory keeps the record, severity and references in one place, and reachability analysis helps you separate code paths that can actually be hit from packages that are merely installed.
A practical way to close this out is to record the affected component, the owner, the target version and a due date in your tracker, then verify the result after the change rather than assuming the update took. Re-run your dependency or inventory check a week later to catch machines that missed it.
Quick check
Is removing a user enough?
Not on affected builds. Upgrade and consider rotating credentials so that old tokens stop working.
Sources
Last reviewed: 19 October 2026.
