CVE-2024-1666: Lunary Authorization Bypass Vulnerability

CVE-2024-1666 Overview

CVE-2024-1666 is an authorization flaw in lunary-ai/lunary version 1.0.0 that allows unauthorized radar creation. The application enforces the free-account restriction only in the web user interface. The server does not perform an equivalent check during the radar creation process. Attackers can bypass the account upgrade requirement by sending crafted requests directly to the backend API. This enables the creation of an unlimited number of radars without payment, defeating the intended commercial tier control.

Critical Impact

Remote, unauthenticated abuse of business logic enables attackers to bypass paid-tier restrictions and create unlimited radars, causing revenue loss and potential resource exhaustion on Lunary infrastructure.

Affected Products

• lunary-ai/lunary version 1.0.0
• Lunary self-hosted deployments prior to the fix commit c57cd50fa0477fd2a2efe60810c0099eebd66f54
• Lunary managed instances running the affected release

Discovery Timeline

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

Technical Details for CVE-2024-1666

Vulnerability Analysis

The vulnerability is a business logic flaw classified under [CWE-770: Allocation of Resources Without Limits or Throttling]. Lunary implements a tiered commercial model in which free-account users are restricted from creating radars. That restriction is enforced client-side in the web UI rather than in the API request handler on the server.

When a user interacts with the web application, the front-end suppresses the radar creation action for free accounts. The backend endpoint responsible for creating radar resources does not verify the caller's subscription tier before persisting the new radar. Any authenticated caller can invoke the endpoint directly and create an unbounded number of radars.

The impact is limited to integrity of the resource allocation policy. Confidentiality and availability are not directly affected, though unbounded creation can lead to secondary resource exhaustion on the Lunary backend.

Root Cause

The root cause is missing server-side authorization enforcement. The application trusted the web UI to gate the radar creation workflow instead of re-validating the account tier inside the API handler. This is a classic broken access control pattern in which security decisions rely on client-side controls.

Attack Vector

Exploitation requires network access to the Lunary API and a valid account session. An attacker uses an HTTP client such as curl or an intercepting proxy to replay the radar creation request that the UI would normally suppress. Because no tier check exists on the server, each replayed request produces a new radar. No user interaction and no privileged credentials are needed beyond a free-tier account.

The vulnerability is described in prose only because no verified public exploit code has been released. Technical details are available in the Huntr bounty writeup and the upstream commit.

Detection Methods for CVE-2024-1666

Indicators of Compromise

• Free-tier user accounts associated with an unusually high number of radar objects in the Lunary database.
• Direct API calls to the radar creation endpoint originating from non-browser user agents such as curl, python-requests, or Postman.
• Bursts of successful radar creation requests from a single account within a short window.

Detection Strategies

• Query the Lunary database to enumerate radar counts per user and flag free-tier accounts exceeding the documented UI limit.
• Instrument the radar creation API handler to log the caller's account tier alongside each request and alert on tier mismatches.
• Correlate web server access logs with subscription records to identify accounts bypassing the intended upgrade flow.

Monitoring Recommendations

• Enable API request logging on the reverse proxy or application gateway fronting Lunary and retain logs for retrospective analysis.
• Configure rate limiting and per-account quotas on the radar endpoint to surface abusive patterns quickly.
• Review billing and subscription telemetry for accounts whose feature usage exceeds their entitlement.

How to Mitigate CVE-2024-1666

Immediate Actions Required

• Upgrade lunary-ai/lunary to a release that includes commit c57cd50fa0477fd2a2efe60810c0099eebd66f54 or later.
• Audit existing radar objects and remove any created by free-tier accounts that exceed the intended quota.
• Rotate API keys for any accounts observed exploiting the endpoint and review associated activity.

Patch Information

The maintainers addressed the flaw in the upstream commit referenced in the Lunary GitHub commit c57cd50. The patch adds server-side verification of the account tier during radar creation so the endpoint enforces the same restriction as the web UI. Self-hosted operators should redeploy from a build that contains this commit.

Workarounds

• Place the Lunary API behind an authorization proxy that inspects the caller's subscription tier and blocks radar creation requests from free-tier accounts.
• Apply strict per-account rate limits on the radar creation route to reduce the practical impact until the patch is deployed.
• Temporarily disable radar creation for all accounts if the tier lookup cannot be enforced externally.

# Example NGINX rate limit for the radar creation endpoint
limit_req_zone $http_authorization zone=radar_create:10m rate=5r/m;

location /api/v1/radars {
    limit_req zone=radar_create burst=2 nodelay;
    proxy_pass http://lunary_backend;
}