CVE-2024-3501 is a high severity information disclosure flaw (CVSS 8.1) in lunary-ai lunary up to and including 1.2.5, where the API returned single use tokens. The record says version 1.2.6 fixes it. Upgrade to 1.2.6 or later and expire any tokens issued before the upgrade.
What's affected
The record says lunary-ai/lunary versions up to and including 1.2.5 are affected and that the issue was addressed in version 1.2.6. The weakness is CWE-922 (insecure storage of sensitive information). The CVSS vector in the record says the attack is reached over the network, with low attack complexity, needing low privileges and no user interaction.
The description says the responses of two endpoints include single use tokens, intended for sensitive operations such as password resets or account verification, in the responses of GET /v1/users/me and GET /v1/users/me/org. The tokens could let an unauthorised party act on behalf of the user. The record's KEV flag is false, so CISA's Known Exploited Vulnerabilities catalog did not list it when this record was captured.
I could not read the linked commit or the Huntr report, so the fix details come from the NVD description.
How to check if you're exposed
Lunary is usually self hosted as a container or from source. Check the version you run: for Docker, look at the image tag, and for a source install, read the version in the project's package file. Anything at 1.2.5 or below needs the upgrade.
Then ask who can reach the API. The vector needs a logged in user, so shared or multi tenant installs matter most. You can also run a free in-browser dependency scan at gold.safeguard.sh/scan to see which known vulnerabilities touch the open source packages you ship.
Safeguard's reachability analysis helps with the next question, which is whether the vulnerable code is actually called in your application, so you can order the work sensibly.
What to do now
- Find every Lunary deployment and its version.
- Upgrade to 1.2.6 or later.
- Treat tokens and recovery values issued before the upgrade as exposed. Expire outstanding reset or verification tokens and ask affected users to reset passwords if you can.
- Check API gateway and application logs that may have stored response bodies from the two endpoints, and limit who can read them.
- Restrict who can create accounts on the instance.
Why it matters
The API returned fields that clients had no need to see. Sensitive values such as reset tokens or recovery hashes should stay on the server and never appear in a response body, even to the account holder, because logs, browser extensions and proxies may keep response bodies. The classes involved are insecure storage and exposure of sensitive information in output.
Developers can cut this risk by returning explicit allow lists of fields, instead of whole database records. The record's KEV flag is false, so CISA's Known Exploited Vulnerabilities catalog did not list it when this record was captured.
Try it yourself
Click through it at your own pace, or open it full screen.
Quick check
Which versions fix it?
Version 1.2.6, per the record. Versions up to and including 1.2.5 are affected.
Sources
- NVD record data for CVE-2024-3501
- Reference links listed in the record (project commit and Huntr report), not fetched for this post: https://github.com/lunary-ai/lunary/commit/17e95f6c99c7d5ac4ee5451c5857b97a12892c74, https://huntr.com/bounties/8fdfdb9d-10bd-4f00-8004-d5baabc20c6e
Last reviewed: 19 October 2026.
