CVE-2024-1902 is a high severity (CVSS 7.5) flaw in the open source Lunary LLM observability project. A user removed from an organization can reuse an old authorization token to rename the organization. The record links a fixing commit but gives no release number, so confirm your build includes it.
What's affected
The NVD record names lunary-ai/lunary without a version range. It links a GitHub commit (d8e2e73e) and a huntr bounty report. The record does not state which release first contains the fix, so confirm your deployment includes that commit or a later one.
The affected code is the orgs.patch route. NVD scores the issue 7.5 (High) with vector CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:N, so the impact is on integrity only.
How to check if you're exposed
If you self host Lunary, check which version or commit your deployment runs. For a Docker deployment, compare the image tag or digest with the project's releases. For a source checkout, run git log in the repository and look for the fix commit linked in the record, or confirm your checkout is newer than it.
Also check your own access records. Any person removed from an organization before the fix could have kept a working token until it expired. Review organization name changes in your audit data for edits made by accounts that no longer belong.
What to do now
- Find every Lunary deployment you run, self hosted or otherwise.
- Update to a build that includes the fixing commit, and confirm with the project's release notes.
- Rotate or invalidate tokens for users who have left an organization.
- Review recent organization name changes for edits by removed accounts.
- Make offboarding revoke sessions, not only membership.
Why it matters
The NVD classification is CWE-821, incorrect synchronization. The description says the server did not check whether a user was still a member of the organization before it allowed the change. Membership was checked when the token was issued, not when it was used.
That pattern appears in many multi tenant products. A token is a snapshot of a past decision, and if the server never re-checks the underlying relationship, removing a person from the group does not remove their power. The practical lesson for any application you build is to authorize on every request against current state, and to expire or revoke sessions when roles change. Here the damage is limited to integrity, but organization names show up in billing, invites and audit trails, so tampering is not harmless. The record's KEV flag is false. You can also run a free in-browser dependency scan at gold.safeguard.sh/scan to see which of your projects pull in the affected component. Safeguard reachability analysis can then help you separate code paths that actually call the weak component from those that only list it.
Quick check
Does removing a user from the organization revoke their access?
Per the description, not for this route. The old token still worked for renaming the organization because membership was not re-checked.
Which release fixes it?
The record links a commit rather than a release. Check the Lunary release notes for the first release that contains it.
Sources
- Fixing commit on GitHub (listed in the NVD record, not readable when retrieved)
- huntr bounty report (listed in the NVD record, not readable when retrieved)
Last reviewed: 19 October 2026.
