CVE-2024-3502 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 account recovery hashes in the responses of GET /v1/users/me and GET /v1/users/me/org. The record says version 1.2.6 fixes it. Upgrade to 1.2.6 or later.
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-201 (insertion of sensitive information into sent data), 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 account recovery hashes in the responses of GET /v1/users/me and GET /v1/users/me/org. The record notes the hashes are not directly related to user passwords, but they could help account recovery attacks or other misuse. 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.
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-3502
- 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/c2aff952-2dec-4538-8905-190c484aae94
Last reviewed: 19 October 2026.
