mem0 OpenMemory: unauthenticated API exposes agent memories and LLM keys

What is this?

On July 7, 2026, VulnCheck published two advisories against mem0, one of the most widely used open-source memory layers for LLM agents (distributed as the mem0ai PyPI package). Both flaws live in OpenMemory, mem0’s self-hostable server component (openmemory/api), and both share the same root cause: critical HTTP endpoints were registered with no authentication in front of them.

The first advisory covers unauthenticated access to the memory store itself — an attacker who can reach the server can read, write, and delete any user’s memories, and can trip a global pause switch that takes the service down for everyone. The second covers the configuration API, which returns stored LLM API keys in plaintext and can be abused to make the server issue attacker-chosen outbound requests. Both were assigned CVSS scores in the 9.2–9.3 range (critical). The fixes landed in mem0 commit a3154d5; every build up to that commit is affected.

How it works

mem0 gives an agent a persistent memory: facts, preferences, and prior conversation state are written to a store and retrieved on later turns. OpenMemory exposes that store over an HTTP API so multiple agents and front-ends can share it. The vulnerability class here is CWE-306, missing authentication for a critical function — the routers were mounted without an auth dependency, so the endpoints answer to anyone who can open a socket to them.

Two endpoint families are affected. The memory routers accept a caller-supplied user_id and act on whatever value is passed, with no check that the caller owns that identity. Reading another tenant’s memories is therefore a matter of iterating identifiers; writing or deleting them works the same way. A pause endpoint accepts a global_pause=true flag that halts memory operations across the whole deployment — a one-request denial of service.

The config router is worse for secret hygiene. A plain GET on the config path returns the server’s stored provider settings, including LLM API keys in cleartext — the OpenAI or other provider key the deployment uses to talk to its model. Separately, the config for the local-model backend takes a base-URL value (ollama_base_url). Because it is attacker-writable and the server then makes requests to it, setting it to an internal address turns the server into a server-side request forgery (SSRF) proxy — the advisory specifically calls out cloud instance-metadata endpoints as a target, the classic path to short-lived cloud credentials.

Chaining is the real risk. Plaintext key theft plus SSRF to a metadata service means an attacker can walk from an exposed memory server to the model provider bill and, potentially, to the cloud role the instance runs under — without ever authenticating.

Why it matters

Agent memory is becoming standard infrastructure, and self-hosting a memory server feels like the safe, privacy-preserving choice. But a memory layer concentrates exactly the data an attacker wants: everything the agent has learned about its users, plus the credentials it needs to run. When that layer ships assuming it sits on a trusted network and someone exposes it — a container port mapped to 0.0.0.0, a preview deployment on a public IP, an internal service reachable through SSRF elsewhere — the blast radius covers memory integrity (poisoning what the agent “remembers”), confidentiality (reading private memories and keys), and availability (the global pause) at once. Memory poisoning in particular is a quiet failure mode: a planted memory can steer an agent’s later decisions long after the write, with no obvious trace.

Defenses

Do not expose the memory server to any untrusted network. Treat OpenMemory as a backend service: bind it to localhost or a private interface, put it behind an authenticating reverse proxy or gateway, and never map its port to a public address. If you run it in a container, check the published-ports configuration explicitly.

Update past the fix. The patched code is in mem0 commit a3154d5 and later releases. Pin to a fixed version, and treat any build at or before that commit as vulnerable.

Add authentication and per-tenant authorization at the edge. Require a token on every request and verify that the authenticated principal owns the user_id it operates on. Missing authentication and missing object-level authorization are separate bugs; fix both, so a valid token for one tenant cannot read another’s memories.

Get provider keys out of the server’s readable config. Inject LLM API keys from a secrets manager or environment at runtime rather than storing them where a config endpoint can return them, scope keys narrowly, and rotate any key that lived on an exposed instance.

Block the SSRF path. Treat any server-supplied base URL as untrusted: allowlist permitted hosts, deny requests to link-local, loopback, and metadata ranges, and require IMDSv2-style session tokens so a bare SSRF cannot read cloud credentials.

Monitor for the signature. Alert on config reads, on writes that flip a global pause, and on cross-user_id access patterns — the operational fingerprint of this class of attack.

Status

Item	Reference	Date	Notes
Missing auth on memory API	CVE-2026-59705	2026-07-07	Unauthenticated read/write/delete of arbitrary memories; global_pause DoS. CWE-306
Config API key leak + SSRF	CVE-2026-59706	2026-07-07	Plaintext LLM API keys via config GET; SSRF via ollama_base_url. CVSS 9.3 (v3.1) / 9.2 (v4.0), CWE-306
Fix	mem0 commit a3154d5	2026-07	Builds up to and including this commit are affected
Reported by	VulnCheck (CNA)	2026-07-07	Advisories and NVD records published same day
Mapped frameworks	OWASP LLM06 (Excessive Agency) / API Security “Broken Authentication”, MITRE ATLAS AML.T0024 (exfiltration)	2026	Missing auth on an agent-memory service

The mem0 advisories are a reminder that the newest parts of the agent stack — memory, tool servers, config planes — are still shipping with the network-trust assumptions of a local prototype. Publication dates: both advisories and NVD entries are dated July 7, 2026; the fix commit predates disclosure.