CVE-2024-8999: Lunary Auth Bypass Vulnerability

CVE-2024-8999 Overview

CVE-2024-8999 is an improper access control vulnerability in lunary-ai/lunary version 1.4.25. The flaw resides in the POST /api/v1/data-warehouse/bigquery endpoint, which fails to enforce authentication or authorization checks. Any unauthenticated user can invoke the endpoint to create a stream that exports the entire application database to a Google BigQuery destination. Lunary is an open-source observability and analytics platform for large language model (LLM) applications, so the exposed data typically includes prompts, completions, user records, and API metadata. The maintainers addressed the issue in version 1.4.26. The vulnerability is tracked under CWE-862: Missing Authorization.

Critical Impact

Unauthenticated attackers can exfiltrate the complete Lunary database to an attacker-controlled BigQuery instance over the network.

Affected Products

• lunary-ai/lunary version 1.4.25 and earlier
• Self-hosted Lunary LLM observability deployments exposing the data-warehouse API
• Any Lunary instance with the /api/v1/data-warehouse/bigquery route reachable from untrusted networks

Discovery Timeline

• 2025-03-20 - CVE-2024-8999 published to the National Vulnerability Database (NVD)
• 2025-10-15 - Last updated in NVD database

Technical Details for CVE-2024-8999

Vulnerability Analysis

The vulnerability stems from a missing authorization check on the POST /api/v1/data-warehouse/bigquery route. The endpoint accepts a BigQuery configuration payload and initiates a data export stream from the Lunary backend database to the supplied Google BigQuery target. Because the handler does not validate the caller's session, project membership, or role, any network-reachable client can submit the request. The result is a full database egress operation initiated by an unauthenticated principal. The data set typically includes LLM prompts, model responses, user identifiers, and integration secrets stored within Lunary projects, making the exposure relevant to confidentiality of sensitive AI workload telemetry.

Root Cause

The root cause is missing authorization enforcement on a privileged administrative route. Lunary applies authentication middleware to other API surfaces, but the BigQuery data-warehouse handler in version 1.4.25 was registered without the required access control guard. The fix in version 1.4.26, delivered in commit aa0fd22, adds the proper authorization check before the export stream is created.

Attack Vector

The attack vector is network-based and requires no privileges or user interaction. An attacker sends a single HTTP POST request to the vulnerable endpoint with a JSON body containing BigQuery destination credentials they control. The server then streams every record from the Lunary database to the attacker's BigQuery dataset. No exploit code is required beyond a standard HTTP client such as curl. Detailed reproduction steps are documented in the Huntr Bounty Report.

Detection Methods for CVE-2024-8999

Indicators of Compromise

• Unauthenticated or anonymous HTTP POST requests to /api/v1/data-warehouse/bigquery in Lunary access logs
• Outbound network connections from the Lunary host to bigquery.googleapis.com that do not match approved integration projects
• Newly created BigQuery export streams or jobs that were not configured by an administrator
• Sudden increase in read activity or egress bandwidth from the Lunary application database

Detection Strategies

• Audit Lunary HTTP access logs for any request to the /api/v1/data-warehouse/bigquery path and correlate with authenticated session identifiers
• Alert when the data-warehouse endpoint returns a 2xx status without a preceding authenticated session token
• Inspect application logs for BigQuery stream creation events and verify each against the change-management record

Monitoring Recommendations

• Forward Lunary API access logs and database egress metrics to a centralized analytics platform for retention and search
• Monitor egress to Google Cloud APIs from Lunary hosts and flag destinations outside the approved project list
• Track configuration changes to data-warehouse integrations and alert on additions made outside maintenance windows

How to Mitigate CVE-2024-8999

Immediate Actions Required

• Upgrade Lunary to version 1.4.26 or later, which includes the authorization fix in commit aa0fd22
• Restrict network access to the Lunary API so the /api/v1/data-warehouse routes are reachable only from trusted administrative networks
• Rotate any BigQuery service account keys, API tokens, and integration secrets stored in Lunary after confirming exposure
• Review BigQuery audit logs in connected Google Cloud projects for unexpected stream creation since deployment of version 1.4.25

Patch Information

The maintainers fixed the issue in lunary-ai/lunary version 1.4.26. The patch is published in the upstream repository as commit aa0fd22952d1d84a717ae563eb1ab564d94a9e2b and adds the missing authorization check to the BigQuery data-warehouse handler. Operators running self-hosted deployments should pull the updated container image or rebuild from the tagged release.

Workarounds

• Block the /api/v1/data-warehouse/bigquery route at an upstream reverse proxy or web application firewall until the upgrade is applied
• Place the Lunary API behind an authenticating gateway that rejects unauthenticated requests to data-warehouse endpoints
• Apply egress filtering on the Lunary host to allow connections only to approved Google Cloud projects

# Example NGINX rule to block the vulnerable endpoint until patching
location = /api/v1/data-warehouse/bigquery {
    return 403;
}