CVE-2024-9099
Lunary 1.4.29
Raw vector
CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:NSummary
CVE-2024-9099 is a high-severity Exposure of Sensitive Information Through Metadata (CWE-1230) vulnerability in Lunary Lunary. Its CVSS base score is 8.1 (High).
Operationally, exploitation aligns with the MITRE ATT&CK technique Data from Local System (T1005); ranked at the 43th percentile by exploit likelihood (below the median); it is not currently listed in the CISA KEV catalog; a public proof-of-concept is referenced.
This vulnerability is AI-related — categorised as LLM Application Platforms; in the Privacy and Disclosure risk domain.
The strongest mitigations our analysis identified map to AC-4 (Information Flow Enforcement) and AC-16 (Security and Privacy Attributes) — see the control section below for these in your framework.
Deeper analysis AI-assisted summary
Synthesised by an AI model from the NVD description and linked references — a reading aid, not an authoritative source.
CVE-2024-9099 is a vulnerability in lunary-ai/lunary version v1.4.29, where the GET /projects API endpoint exposes both public and private API keys for all projects to users with minimal permissions, such as Viewers or Prompt Editors. The private API keys become visible in the developer tools when the endpoint is called from the frontend, enabling unauthorized access to sensitive credentials.
Attackers require only low-privilege access (PR:L), such as a Viewer or Prompt Editor role, to exploit this remotely (AV:N) with low attack complexity (AC:L) and no user interaction (UI:N), earning a CVSS v3.1 base score of 8.1 (C:H/I:H/A:N). Successful exploitation allows retrieval of the API keys, which can then be used to perform actions on behalf of the affected project, access private data, and delete resources.
A fix is available via commit 8ba1b8ba2c2c30b1cec30eb5777c1fda670cbbfc in the lunary-ai/lunary GitHub repository. Further details on the vulnerability and remediation are provided on the Huntr bounty page at https://huntr.com/bounties/ffb84fe8-3e60-4200-ac2d-1fd1e1c93e91.
EU & UK References
- 🇪🇺 ENISA EUVD: EUVD-2025-6863
Vulnerability Data
In lunary-ai/lunary version v1.4.29, the GET /projects API endpoint exposes both public and private API keys for all projects to users with minimal permissions, such as Viewers or Prompt Editors. This vulnerability allows unauthorized users to retrieve sensitive credentials, which…
more
can be used to perform actions on behalf of the project, access private data, and delete resources. The private API keys are exposed in the developer tools when the endpoint is called from the frontend.
- CWE(s)
AI Security AnalysisAI
- AI Category
- LLM Application Platforms
- Risk Domain
- Privacy and Disclosure
- OWASP Top 10 for LLMs 2025
- None mapped
- Classification Reason
- Matched keywords: ai, lunary
Related Threats
MITRE ATT&CK Enterprise Techniques
CVEs Like This One
Affected Assets
Mitigating Controls
Control response
—
—
- 1 hardening rule · 1 OS baseline
V3.4.2V12.1.5V13.3.2V14.2.4
Mitigating Controls (NIST 800-53 r5) AI
Information flow enforcement can be configured to treat metadata as protected information and block its unauthorized release.
Associating and enforcing security/privacy attributes on objects directly governs what metadata may be exposed.
Requiring security attributes to accompany transmitted data prevents sensitive values from leaking through metadata channels.
Mitigating Controls (NIST CSF 2.0) AI
Derived directly from the weakness types (CWEs) cited in the NVD entry via our AI-authored CWE→CSF cross-walk (authority under review) — links open the control.
Mitigating Controls (ISO/IEC 27001:2022 Annex A) AI
Derived directly from the weakness types (CWEs) cited in the NVD entry via our AI-authored CWE→ISO cross-walk (authority under review) — links open the control.
Classification helps identify metadata that may need protection, but does not directly limit its exposure.
Labelling can flag sensitive metadata, yet does not enforce technical controls to prevent its disclosure.
Transfer policies can require stripping or protecting metadata, but coverage is indirect.
Access-control rules can be extended to metadata objects, though the control is not metadata-specific.
Data-masking techniques can obscure sensitive metadata values, providing partial mitigation.
DLP solutions can detect and block metadata leakage, yet are not designed solely for this weakness.