CVE-2024-6862: Lunary CSRF Vulnerability via CORS Issue

CVE-2024-6862 Overview

CVE-2024-6862 is a Cross-Site Request Forgery (CSRF) vulnerability affecting lunary-ai/lunary version 1.2.34. The flaw stems from overly permissive Cross-Origin Resource Sharing (CORS) settings that permit all origins to interact with unauthenticated backend endpoints. Attackers can leverage this misconfiguration to sign up accounts and create projects on a target instance as if they held local access. The primary attack surface involves Lunary instances hosted locally on personal machines that are not publicly accessible. The vulnerability is classified under CWE-352.

Critical Impact
A remote attacker can trick an authenticated victim's browser into issuing cross-origin requests that create accounts or projects on a local Lunary instance, breaking the trust boundary of locally hosted deployments.

Affected Products

lunary-ai/lunary version 1.2.34
Self-hosted Lunary instances exposing the backend API
Local deployments relying on origin restrictions for protection

Discovery Timeline

2024-09-13 - CVE-2024-6862 published to NVD
2026-06-17 - Last updated in NVD database

Technical Details for CVE-2024-6862

Vulnerability Analysis

The vulnerability resides in the Lunary backend CORS configuration. The server responds to cross-origin preflight and simple requests with permissive headers that accept any Origin value. Browsers therefore allow JavaScript hosted on attacker-controlled sites to issue authenticated or unauthenticated requests against the Lunary API. Because the affected endpoints do not require CSRF tokens or strict origin checks, the attacker can execute state-changing operations such as user signup and project creation. Local-only deployments suffer the highest exposure since operators frequently assume that binding to localhost provides adequate isolation.

Root Cause

The root cause is an insecure CORS policy paired with missing CSRF protection on state-changing endpoints. The backend reflects or wildcards the Access-Control-Allow-Origin header without validating the requester's origin against an allowlist. Sensitive operations including account registration are exposed without anti-CSRF tokens or SameSite cookie enforcement, matching the pattern described in CWE-352.

Attack Vector

An attacker hosts a malicious web page and lures a Lunary operator to visit it. The page issues background fetch or XMLHttpRequest calls targeting http://localhost or the victim's Lunary host. Because CORS permits all origins, the browser delivers the requests and allows the attacker to read or write data through the unauthenticated signup and project APIs. The attacker can then authenticate to the newly created account and interact with the instance.

No verified public exploit code is available. See the Huntr bounty submission for additional technical context.

Detection Methods for CVE-2024-6862

Indicators of Compromise

Unexpected user accounts appearing in the Lunary user table without corresponding operator activity
Project creation events originating from referers that are not the official Lunary frontend
HTTP request logs containing Origin headers from third-party domains targeting /auth/signup or project endpoints

Detection Strategies

Inspect backend access logs for cross-origin requests where the Origin header does not match the deployed Lunary frontend domain
Correlate signup events with browser referer headers to identify requests initiated from external pages
Audit the running Lunary version against the fixed commit to confirm whether the permissive CORS policy is still in place

Monitoring Recommendations

Enable verbose HTTP logging on the Lunary backend and forward logs to a centralized SIEM for analysis
Alert on bursts of account creation events from a single client IP or originating from non-standard origins
Monitor outbound DNS and proxy logs on operator workstations for connections to suspicious sites that could host CSRF payloads

How to Mitigate CVE-2024-6862

Immediate Actions Required

Upgrade Lunary beyond version 1.2.34 to a release containing commit 3451fcd7b9d95e9091d62c515752f39f2faa6e54
Restrict network access to local Lunary instances using host firewall rules until the patch is applied
Sign out of Lunary in shared browsers and clear session cookies on operator workstations

Patch Information

The Lunary maintainers addressed the issue in commit 3451fcd7b9d95e9091d62c515752f39f2faa6e54, which tightens the backend CORS policy. Operators running version 1.2.34 should pull the latest release from the lunary-ai/lunary repository and redeploy.

Workarounds

Place Lunary behind a reverse proxy that enforces an explicit Access-Control-Allow-Origin allowlist matching only trusted frontend domains
Block third-party cookies in operator browsers and set SameSite=Strict on Lunary session cookies where supported
Avoid browsing untrusted websites in the same browser session used to administer a local Lunary instance

bash

# Example nginx reverse proxy CORS allowlist
location /api/ {
    if ($http_origin !~ ^https://lunary\.internal\.example\.com$) {
        return 403;
    }
    add_header Access-Control-Allow-Origin $http_origin always;
    add_header Access-Control-Allow-Credentials true always;
    proxy_pass http://127.0.0.1:3333;
}