CVE-2024-1626: Lunary IDOR Auth Bypass Vulnerability

CVE-2024-1626 Overview

CVE-2024-1626 is an Insecure Direct Object Reference (IDOR) vulnerability in the lunary-ai/lunary repository, version 0.3.0. The flaw resides in the project update endpoint at /v1/projects/:projectId, which fails to verify ownership of the referenced project. Authenticated users can issue a PATCH request against any project identifier and rename projects belonging to other organizations. The weakness maps to CWE-639: Authorization Bypass Through User-Controlled Key.

Critical Impact
Any authenticated tenant can rename arbitrary projects across organizational boundaries, breaking tenant isolation and enabling cross-tenant data tampering in the Lunary AI observability platform.

Affected Products

lunary-ai/lunary version 0.3.0
Lunary project update API endpoint /v1/projects/:projectId
Multi-tenant deployments of Lunary prior to commit 9eb9e526edff8bf82ae032f7a04867c8d58572bc

Discovery Timeline

2024-04-16 - CVE-2024-1626 published to the National Vulnerability Database
2026-06-17 - Last updated in NVD database

Technical Details for CVE-2024-1626

Vulnerability Analysis

The Lunary application exposes a PATCH /v1/projects/:projectId route that updates a project's metadata, including its display name. The handler trusts the projectId path parameter from the request and applies the requested change without confirming that the authenticated session owns the project. Because Lunary supports multiple organizations within a single deployment, an attacker only needs valid credentials for any tenant to enumerate or guess project identifiers and modify resources outside their authorization scope. The vulnerability falls under the broader category of broken object-level authorization, a recurring class of API flaws.

Root Cause

The project update controller lacks an authorization check that ties the requested projectId to the requesting user's organization. The endpoint performs authentication but conflates it with authorization, treating any logged-in user as eligible to mutate any project record. The patch in commit 9eb9e526edff8bf82ae032f7a04867c8d58572bc introduces an ownership verification step before the database write. Refer to the GitHub commit for the corrective logic.

Attack Vector

Exploitation requires only an authenticated session and network access to the Lunary API. An attacker authenticates with their own low-privilege account, then sends a PATCH request to /v1/projects/:projectId supplying the identifier of a project owned by a different organization. The server applies the new name value without rejecting the request. No user interaction by the victim is needed, and exploitation can be scripted to iterate across enumerated project IDs. Technical details are documented in the Huntr bounty report.

Detection Methods for CVE-2024-1626

Indicators of Compromise

Unexpected changes to project names visible in the Lunary administration interface or audit history
PATCH requests to /v1/projects/:projectId where the authenticated user's organization does not match the targeted project owner
Spikes in 4xx/2xx responses against /v1/projects/* from a single account enumerating multiple project IDs

Detection Strategies

Inspect application access logs for PATCH /v1/projects/ calls and correlate the projectId against the requester's organization in the database
Add server-side audit logging that records the authenticated user identifier, the target projectId, and the resulting field changes for every project mutation
Alert when the same user identifier mutates projects belonging to more than one organization within a defined time window

Monitoring Recommendations

Forward Lunary API logs to a centralized logging or SIEM platform and create alerts for cross-tenant project modifications
Track historical project-name changes and surface diffs to administrators for review
Monitor for sequential numeric or UUID enumeration patterns in the :projectId parameter

How to Mitigate CVE-2024-1626

Immediate Actions Required

Upgrade Lunary beyond version 0.3.0 to a release that includes commit 9eb9e526edff8bf82ae032f7a04867c8d58572bc
Audit existing project records for unauthorized name changes and restore impacted values from backups where needed
Rotate API tokens for any accounts suspected of abusing the endpoint and review recent authentication logs

Patch Information

The fix is delivered in upstream commit 9eb9e526edff8bf82ae032f7a04867c8d58572bc, which adds an authorization check confirming that the requesting user belongs to the organization that owns the targeted project before applying updates. Operators running self-hosted Lunary deployments should rebuild or redeploy from a version that contains this commit.

Workarounds

Place the Lunary API behind a reverse proxy or API gateway that enforces tenant-scoped access policies on /v1/projects/:projectId
Temporarily restrict PATCH access to /v1/projects/* to administrative accounts until the upgrade is applied
Implement application-layer middleware that rejects project mutation requests when the path projectId does not match the authenticated user's organization

bash

# Example reverse-proxy guard (nginx) blocking unauthenticated PATCH calls
# until upstream Lunary is upgraded to a patched build.
location ~ ^/v1/projects/[^/]+$ {
    limit_except GET {
        # Require an internal admin header injected by your auth proxy
        if ($http_x_internal_admin != "1") { return 403; }
    }
    proxy_pass http://lunary_upstream;
}