Cognee's settings endpoint let any registered user repoint the whole instance's LLM provider

In brief A vulnerability disclosed on July 7, 2026 in Cognee — a popular open-source “AI memory” platform for agents — shows a settings endpoint that changed the instance-wide LLM provider configuration without any admin or superuser check. Any user who could self-register was able to point every model call on the server at an endpoint they controlled, turning the memory engine into a data-exfiltration channel for all users. It affects Cognee before 1.2.0; the fix is in 1.2.0. This is a broken-authorization writeup, not an exploit.

What is this?

Cognee is an open-source memory layer for LLM agents: you .add() documents, .cognify() them into a knowledge graph with embeddings, and .search() over the result. It combines a graph store, a vector store, and relational metadata into one “persistent memory” service, is Apache-2.0 licensed with well over ten thousand GitHub stars, and is deployed both self-hosted and multi-user.

The flaw, published to the CVE ecosystem on July 7, 2026 and documented in a VulnCheck advisory and Cognee’s own issue tracker, is a missing authorization check on the settings API. The route that writes the server’s LLM provider configuration performed no admin or superuser verification, so any account — including one an attacker created themselves through open self-registration — could overwrite it. It is rated CVSS 9.1 (critical), with high confidentiality and integrity impact and the weakness classed as missing authentication for a critical function.

How it works

There is no exotic payload here. The problem is who is allowed to call a privileged function, and the answer was “anyone.” The sequence looks like this:

Instance-wide provider hijack (vulnerable versions)
---------------------------------------------------
1. Attacker self-registers a normal account on the Cognee instance
2. Attacker calls the settings endpoint to write the LLM provider config
   --> no admin / superuser check is performed
3. Config points the base URL / provider at an attacker-controlled endpoint
4. A process-wide singleton caches that config for the whole server
5. Every user's .cognify() and .search() now routes prompts + documents
   through the attacker's endpoint

The critical amplifier is step 4. Because the configuration lives in a process-wide singleton cache, one write does not just affect the attacker’s own session — it changes the provider for the entire instance. From that point, prompts, uploaded documents, extracted entities, and knowledge-graph content belonging to every user flow through infrastructure the attacker controls. A confidentiality breach (read everyone’s data) and an integrity breach (return manipulated model output back into the shared memory) land at the same time, with no privileges and no user interaction required.

Why it matters

Agent “memory” platforms are becoming trusted shared infrastructure: teams pour internal documents, chat history, and extracted entities into them precisely so multiple agents and users can query a common brain. That makes the provider configuration a crown-jewel setting — it decides where every prompt and every document is sent. Treating “change the model endpoint” as an ordinary user action, rather than a privileged administrative one, collapses the tenant boundary entirely.

The broader lesson is not specific to one project. As LLM tooling races to add settings pages, admin panels, and self-service registration, the classic web-app failure — a state-changing endpoint that never checks the caller’s role — reappears with a heavier blast radius, because a single writable field now controls the routing of all AI traffic on the box. A global singleton that any authenticated caller can rewrite is broken access control (CWE-306 / missing function-level authorization), the same bug the OWASP Top 10 has warned about for years, wearing an AI costume.

Defenses

1. Upgrade to Cognee 1.2.0 or later. The fix adds the authorization check to the settings path; if you self-host, patch first and check the release notes for any config you need to re-set.
2. Lock down registration and network exposure. Don’t leave open self-registration on an internet-reachable memory instance. Put it behind authenticated ingress and restrict who can reach the API at all.
3. Enforce function-level authorization on every state-changing route. Any endpoint that writes global or provider configuration must verify an admin/superuser role server-side — never rely on the UI hiding the button. Audit your own AI tooling for settings routes that skip this.
4. Treat provider/base-URL config as a privileged secret. Pin the allowed provider endpoints via environment or deployment config rather than a runtime-writable field, and alert on any change to the model base URL.
5. Watch egress from the memory service. Model calls suddenly leaving to an unexpected host is a high-signal indicator; monitor and allowlist outbound destinations from inference and memory components.

Status

Item	Reference	Date	Notes
Advisory	VulnCheck — CVE-2026-58473	2026-07-07	Unauthorized LLM config overwrite via settings API
Weakness class	CWE-306	—	Missing authentication / authorization for a critical function
Severity	CVSS 3.1 base 9.1 (critical)	—	AV:N/AC:L/PR:N/UI:N — high confidentiality & integrity impact
Affected versions	Cognee	< 1.2.0	Multi-user / self-hosted deployments with self-registration
Patched version	Cognee 1.2.0	2026-07	Admin check added to the settings path (commit d10b1b7)

The honest framing is not “an AI memory got hacked.” It is that a shared memory service routes everyone’s data through one configurable endpoint, and the oldest rule of access control still applies: a function that changes what the whole server does must check that the caller is allowed to change it.