CVE-2025-4962: Lunary API Auth Bypass Vulnerability

CVE-2025-4962 Overview

CVE-2025-4962 is an Insecure Direct Object Reference (IDOR) vulnerability in the Lunary API. The flaw affects the POST /v1/templates endpoint in Lunary versions up to and including 0.8.8. Authenticated users can create templates inside another user's project by manipulating the projectId query parameter. The server does not validate that the authenticated user owns the specified project. Lunary has addressed the issue in version 1.9.23. The weakness is classified under CWE-284 (Improper Access Control).

Critical Impact
Any authenticated Lunary user can write templates into projects belonging to other tenants, breaking project isolation and integrity guarantees.

Affected Products

Lunary API versions up to and including 0.8.8
Lunary POST /v1/templates endpoint
Fixed in Lunary version 1.9.23

Discovery Timeline

2025-08-18 - CVE-2025-4962 published to NVD
2026-06-17 - Last updated in NVD database

Technical Details for CVE-2025-4962

Vulnerability Analysis

The vulnerability resides in the template creation handler exposed at POST /v1/templates. The endpoint accepts a projectId query parameter that determines where the new template is stored. Lunary trusts the supplied projectId without confirming that the authenticated principal owns or has access to that project.

This is a textbook Insecure Direct Object Reference issue. The server reads a user-controlled object identifier and uses it directly in a privileged operation. Authorization is implicit rather than enforced. The attack changes integrity, not confidentiality, because the attacker writes data into another tenant's project rather than reading from it.

Root Cause

The root cause is missing server-side authorization. The handler verifies authentication but does not check ownership of the projectId against the session principal. Any valid account token combined with a known or guessed project identifier is sufficient to operate on resources outside the user's authorization scope.

Attack Vector

An attacker authenticates to the Lunary API using any valid account. The attacker then sends a POST request to /v1/templates and supplies the target tenant's projectId as a query parameter. The server creates the template inside the victim's project. Project identifiers can be discovered through enumeration, shared links, logs, or other side channels.

No verified public exploit code is associated with this CVE. See the Huntr bounty listing and the upstream commit for additional technical detail.

Detection Methods for CVE-2025-4962

Indicators of Compromise

Unexpected templates appearing in a project that the project owner did not create.
POST /v1/templates requests where the request projectId does not match the authenticated user's owned project list.
API access logs showing the same user account writing templates across multiple, unrelated projectId values.

Detection Strategies

Audit Lunary API access logs and correlate the authenticated user identifier with the projectId query parameter for every POST /v1/templates call.
Compare template creation events against project membership records to identify cross-tenant writes.
Alert on enumeration patterns where one account submits requests against many distinct projectId values in a short time window.

Monitoring Recommendations

Forward Lunary API logs to a centralized analytics platform for retention and query.
Build alerts on anomalous template creation rates per user account.
Track HTTP 2xx responses to POST /v1/templates requests originating from accounts that historically interact with only one project.

How to Mitigate CVE-2025-4962

Immediate Actions Required

Upgrade Lunary to version 1.9.23 or later, which contains the authorization fix.
Review template inventories for each project and remove entries created by unauthorized accounts.
Rotate API tokens associated with any account confirmed to have abused the endpoint.

Patch Information

Lunary fixed the vulnerability in version 1.9.23. The relevant change is documented in the upstream GitHub commit. The patch adds server-side validation that the authenticated user owns the projectId supplied to the POST /v1/templates endpoint.

Workarounds

Place the Lunary API behind a reverse proxy that enforces an allowlist mapping authenticated identities to permitted projectId values.
Restrict access to the Lunary API to trusted networks until the upgrade is applied.
Disable or gate the POST /v1/templates endpoint at the proxy layer if the workflow can tolerate it during the upgrade window.

bash

# Example reverse proxy guard: reject template writes that omit ownership headers
# (apply only as a temporary control before upgrading to 1.9.23)
location = /v1/templates {
    if ($request_method = POST) {
        if ($http_x_verified_project_owner != "true") { return 403; }
    }
    proxy_pass http://lunary_upstream;
}