CVE-2024-3502: Lunary Information Disclosure Vulnerability

CVE-2024-3502 Overview

CVE-2024-3502 is an information disclosure vulnerability in lunary-ai/lunary versions up to and including 1.2.5. The application inadvertently returns account recovery hashes in API responses from the GET /v1/users/me and GET /v1/users/me/org endpoints. Any authenticated user can inspect these responses and retrieve recovery hash material belonging to their own account context. While the exposed hashes are not user passwords, they constitute sensitive credential-adjacent material that should remain server-side. The issue was remediated in version 1.2.6.

Critical Impact

Authenticated attackers can harvest account recovery hashes from standard user profile endpoints, enabling downstream account recovery abuse and identity compromise in Lunary AI deployments.

Affected Products

• Lunary AI lunary versions up to and including 1.2.5
• Self-hosted Lunary deployments exposing /v1/users/me endpoints
• Lunary instances using account recovery workflows

Discovery Timeline

• 2024-11-14 - CVE-2024-3502 published to the National Vulnerability Database (NVD)
• 2025-10-15 - Last updated in NVD database

Technical Details for CVE-2024-3502

Vulnerability Analysis

Lunary is an observability and analytics platform for large language model (LLM) applications. The vulnerability falls under Information Exposure to an Unauthorized Actor [CWE-201] and Insertion of Sensitive Information into Externally-Accessible File or Directory [CWE-922]. Authenticated requests against GET /v1/users/me and GET /v1/users/me/org return serialized user objects that include recoveryHash fields. The server-side controller fails to strip these sensitive properties before returning the JSON payload to the client.

The attack requires only low-privilege authenticated access. There is no requirement for administrative roles, multi-step interaction, or user assistance. An attacker holding any valid session can issue a single HTTP request to retrieve the hash material associated with the response context.

Root Cause

The root cause is missing output filtering on user serialization. The Lunary backend returns the full user database record rather than a sanitized data transfer object. Sensitive columns such as the recovery hash are included alongside benign profile fields like name and email. The fix in commit 17e95f6c99c7d5ac4ee5451c5857b97a12892c74 removes these fields from the response model.

Attack Vector

The attack vector is network-based against the Lunary HTTP API. An attacker authenticates with valid credentials, then issues GET /v1/users/me or GET /v1/users/me/org. The JSON response contains the recoveryHash value. The attacker can then attempt offline hash analysis or replay the value against account recovery flows that accept the hash as a proof of possession.

No verified public proof-of-concept code is available. Refer to the Huntr Bounty Listing and the GitHub Commit Details for remediation context.

Detection Methods for CVE-2024-3502

Indicators of Compromise

• HTTP 200 responses from /v1/users/me or /v1/users/me/org containing a recoveryHash JSON field on Lunary versions 1.2.5 or earlier
• Unusual volumes of authenticated requests to user profile endpoints from a single session or token
• Subsequent account recovery requests that succeed without normal email-based challenge flows

Detection Strategies

• Inspect application logs and web application firewall (WAF) telemetry for repeated GET /v1/users/me* calls correlated to single accounts.
• Deploy response-body inspection rules that flag outbound JSON payloads containing the literal key recoveryHash from Lunary hosts.
• Compare deployed Lunary commit hash against the patched version 1.2.6 or later during configuration audits.

Monitoring Recommendations

• Enable verbose API access logging on the Lunary backend and forward logs to a centralized analytics platform.
• Alert on access pattern anomalies for self-service profile endpoints, especially from service accounts or automation tokens.
• Monitor account recovery completion events for accounts that did not initiate a recovery request through standard channels.

How to Mitigate CVE-2024-3502

Immediate Actions Required

• Upgrade all Lunary deployments to version 1.2.6 or later without delay.
• Rotate account recovery hashes and force password resets for users who accessed the affected endpoints during the vulnerable window.
• Audit access logs for /v1/users/me and /v1/users/me/org calls predating the upgrade and review accounts with abnormal access patterns.

Patch Information

The vulnerability is fixed in Lunary version 1.2.6. The patch removes the recoveryHash field from API responses returned by the affected endpoints. Review the GitHub Commit Details for the exact code changes applied in commit 17e95f6c99c7d5ac4ee5451c5857b97a12892c74.

Workarounds

• Restrict network access to the Lunary API to trusted internal networks until the upgrade is completed.
• Apply a reverse-proxy response filter that strips recoveryHash keys from JSON bodies returned by /v1/users/me and /v1/users/me/org.
• Invalidate existing recovery hashes by triggering credential rotation procedures across the user base.

# Upgrade Lunary to the patched release
git fetch --tags
git checkout v1.2.6
npm install
npm run build
# Restart the Lunary backend service after deployment