CVE-2024-5133 is a high severity (CVSS 8.1) account takeover flaw in lunary-ai/lunary version 1.2.4. The team listing endpoint returns each user's password recovery token, so any authenticated teammate could reset another user's password. Upgrade and have affected users rotate credentials.
What's affected
The record names lunary-ai/lunary version 1.2.4. The API call named is GET /v1/users/me/org, which lists users in a team and includes a recovery_token attribute in each user object when a reset is in progress.
No fixed version or commit is listed in the record, only a huntr report. Check the Lunary release notes for a release that removes the token from that response, and confirm the number there.
How to check if you're exposed
Identify the version of your deployment:
docker ps --format '{{.Image}}' | grep -i lunary
If you have API access to a test instance, inspect the JSON returned by the team listing for fields that look like secrets. Any token, hash or recovery value in a response meant for display is a finding in itself. Review your own code paths for the same habit of serializing whole database rows.
What to do now
- Upgrade Lunary to a release that no longer returns the recovery token, after confirming in the release notes.
- Invalidate outstanding password reset tokens and ask users who started a reset to restart it.
- Review authentication logs for password changes you cannot match to a user request.
- Enforce multi factor authentication where the product supports it.
- Audit your own APIs for response objects that expose secrets, and use explicit allow lists of fields.
Why it matters
The class is CWE-200, exposure of sensitive information to an unauthorized actor. The reset token is a bearer secret: whoever holds it can set a new password. Placing it in a list endpoint that every team member can call hands that power to the whole team.
It is a quiet bug because nothing is broken from the developer's view. The query returned a row and the serializer returned the row. The fix is allow listing fields in responses. The record does not set the KEV flag, and it requires the attacker to be logged in already, which explains the 8.1 and not a 9.x score.
Quick check
Who can exploit this?
Any authenticated user in the same team, per the record, while a reset is pending.
What should users do?
Reset passwords after upgrading, and restart any password recovery that was in progress.
Sources
Last reviewed: 19 October 2026.
