CVE-2026-59706: mem0: unauth config API leaks API keys + SSRF

CRITICAL PoC AVAILABLE CISA: TRACK*
Published July 7, 2026
CISO Take

mem0, a widely used memory layer for LLM agents, ships config API endpoints that require no authentication at all, letting anyone with network access run a GET against /api/v1/config/ and read back plaintext OpenAI and other LLM provider API keys stored on the server. The same lack of auth lets an attacker PUT a new ollama_base_url pointing at internal infrastructure or cloud metadata services like 169.254.169.254, turning a config field into a full SSRF primitive that can pivot to cloud IAM credential theft — a severity the CVSS 9.3 score (network, no privileges, no user interaction) reflects, though the confidentiality-only vector (C:H/I:L/A:N) understates the downstream blast radius once stolen keys or IMDS-harvested cloud credentials get reused elsewhere. There's no public PoC, Nuclei template, or CISA KEV listing yet, and EPSS data isn't available, so this hasn't been mass-exploited — but the exploit is a single unauthenticated HTTP request, requires zero AI/ML expertise, and the fix commit plus a public GitHub issue (#6081) are already indexed, which shortens the window before opportunistic scanning begins. Patch to the version containing commit a3154d5 immediately, rotate any LLM API keys that may have been exposed on internet- or intranet-reachable mem0 deployments, and until patched put the config API behind a reverse proxy requiring authentication while blocking outbound requests to 169.254.169.254 from the mem0 host.

Sources: NVD CISA KEV GitHub Advisory ATLAS vulncheck.com github.com

What is the risk?

CVSS 9.3 (critical) — network-exploitable, no privileges or user interaction required, a single unauthenticated request to either read (GET) or write (PUT) config. Confidentiality impact is rated high because stored LLM provider API keys are returned in plaintext; integrity impact is rated low in the CVSS vector but that understates real risk, since the same PUT endpoint accepts an attacker-controlled ollama_base_url enabling SSRF against internal services and cloud instance-metadata endpoints (IMDS) — a path to cloud credential theft that CVSS doesn't capture. Not currently in CISA KEV, no EPSS score, no public exploit code or Nuclei template, so there's no evidence of active mass exploitation yet. However, exploitation requires no authentication, no AI/ML-specific knowledge, and no chaining with other bugs, so any internet- or intranet-exposed mem0 deployment should be treated as pre-compromised until patched or shielded.

How does the attack unfold?

Reconnaissance
Attacker scans internet-facing or internal hosts for mem0 server instances exposing default config API paths.
AML.T0006
Exploitation
Attacker sends an unauthenticated GET to /api/v1/config/, exploiting missing authentication (CWE-306) to retrieve plaintext LLM API keys.
AML.T0049
Credential Theft
Harvested OpenAI/LLM API keys are reused to access the victim's LLM provider account directly, bypassing application controls.
AML.T0083
Impact via SSRF
Attacker sends an unauthenticated PUT to /api/v1/config/mem0/llm setting ollama_base_url to cloud IMDS, potentially exfiltrating cloud IAM credentials for further lateral movement.
AML.T0075

How severe is it?

CVSS 3.1
9.3 / 10
EPSS
0.3%
chance of exploitation in 30 days
Higher than 18% of all CVEs
Exploitation Status
Exploit Available
Exploitation: MEDIUM
Sophistication
Trivial
Exploitation Confidence
medium
CISA SSVC: Public PoC
Public PoC indexed (trickest/cve)
Composite signal derived from CISA KEV, VulnCheck KEV, CISA SSVC, EPSS, Metasploit, Exploit-DB, trickest/cve, Nuclei templates, and inthewild.io exploitation reports.

What is the attack surface?

AV AC PR UI S C I A
AV Network
AC Low
PR None
UI None
S Changed
C High
I Low
A None

What should I do?

1 step
  1. 1) Patch: upgrade mem0 to the version including fix commit a3154d59e52386d4e1189c1f5f44819868f76514 (tracked in GitHub issue #6081) as soon as it's available in your deployment channel. 2) Immediate compensating control: never expose the mem0 config API directly to the internet or a flat internal network — front it with a reverse proxy or API gateway enforcing authentication (API key, mTLS, or VPN/ACL-only access). 3) Rotate secrets: treat any LLM API keys stored in a mem0 instance that has ever been reachable without authentication as compromised and rotate them immediately. 4) SSRF containment: block outbound access from the mem0 host to 169.254.169.254 (AWS/Azure) and metadata.google.internal (GCP), and enforce IMDSv2 on AWS so a bare GET/PUT can't retrieve a usable credential even if SSRF succeeds. 5) Detection: alert on unauthenticated GET /api/v1/config/ or PUT /api/v1/config/mem0/llm requests in access logs, and on outbound requests from the mem0 host to link-local/metadata IP ranges.

What does CISA's SSVC say?

Decision Track*
Exploitation poc
Automatable Yes
Technical Impact partial

Source: CISA Vulnrichment (SSVC v2.0). Decision based on the CISA Coordinator decision tree.

How is it classified?

Which compliance frameworks are affected?

This CVE is relevant to:

EU AI Act
Art. 15 - Accuracy, Robustness and Cybersecurity
NIST AI RMF
MANAGE-4.1 - AI system risks and benefits from third-party resources are regularly monitored
OWASP LLM Top 10
LLM06 - Sensitive Information Disclosure LLM07 - Insecure Plugin Design

Frequently Asked Questions

What is CVE-2026-59706?

mem0, a widely used memory layer for LLM agents, ships config API endpoints that require no authentication at all, letting anyone with network access run a GET against /api/v1/config/ and read back plaintext OpenAI and other LLM provider API keys stored on the server. The same lack of auth lets an attacker PUT a new ollama_base_url pointing at internal infrastructure or cloud metadata services like 169.254.169.254, turning a config field into a full SSRF primitive that can pivot to cloud IAM credential theft — a severity the CVSS 9.3 score (network, no privileges, no user interaction) reflects, though the confidentiality-only vector (C:H/I:L/A:N) understates the downstream blast radius once stolen keys or IMDS-harvested cloud credentials get reused elsewhere. There's no public PoC, Nuclei template, or CISA KEV listing yet, and EPSS data isn't available, so this hasn't been mass-exploited — but the exploit is a single unauthenticated HTTP request, requires zero AI/ML expertise, and the fix commit plus a public GitHub issue (#6081) are already indexed, which shortens the window before opportunistic scanning begins. Patch to the version containing commit a3154d5 immediately, rotate any LLM API keys that may have been exposed on internet- or intranet-reachable mem0 deployments, and until patched put the config API behind a reverse proxy requiring authentication while blocking outbound requests to 169.254.169.254 from the mem0 host.

Is CVE-2026-59706 actively exploited?

Proof-of-concept exploit code is publicly available for CVE-2026-59706, increasing the risk of exploitation.

How to fix CVE-2026-59706?

1) Patch: upgrade mem0 to the version including fix commit a3154d59e52386d4e1189c1f5f44819868f76514 (tracked in GitHub issue #6081) as soon as it's available in your deployment channel. 2) Immediate compensating control: never expose the mem0 config API directly to the internet or a flat internal network — front it with a reverse proxy or API gateway enforcing authentication (API key, mTLS, or VPN/ACL-only access). 3) Rotate secrets: treat any LLM API keys stored in a mem0 instance that has ever been reachable without authentication as compromised and rotate them immediately. 4) SSRF containment: block outbound access from the mem0 host to 169.254.169.254 (AWS/Azure) and metadata.google.internal (GCP), and enforce IMDSv2 on AWS so a bare GET/PUT can't retrieve a usable credential even if SSRF succeeds. 5) Detection: alert on unauthenticated GET /api/v1/config/ or PUT /api/v1/config/mem0/llm requests in access logs, and on outbound requests from the mem0 host to link-local/metadata IP ranges.

What systems are affected by CVE-2026-59706?

This vulnerability affects the following AI/ML architecture patterns: agent frameworks, vector databases, LLM memory layers.

What is the CVSS score for CVE-2026-59706?

CVE-2026-59706 has a CVSS v3.1 base score of 9.3 (CRITICAL). The EPSS exploitation probability is 0.26%.

What is the AI security impact?

Affected AI Architectures

agent frameworksvector databasesLLM memory layers

MITRE ATLAS Techniques

AML.T0049 Exploit Public-Facing Application
AML.T0055 Unsecured Credentials
AML.T0075 Cloud Service Discovery
AML.T0083 Credentials from AI Agent Configuration

Compliance Controls Affected

EU AI Act: Art. 15
NIST AI RMF: MANAGE-4.1
OWASP LLM Top 10: LLM06, LLM07

What are the technical details?

Original Advisory

mem0 contains unauthenticated config API endpoints that expose LLM API keys in plaintext and allow server-side request forgery via attacker-controlled ollama_base_url parameter. Unauthenticated attackers can retrieve stored secrets like OpenAI API keys via GET /api/v1/config/ or trigger SSRF attacks by setting ollama_base_url to internal addresses like cloud IMDS via PUT /api/v1/config/mem0/llm endpoint.

Exploitation Scenario

An attacker scans internet-facing hosts for mem0 server instances and sends an unauthenticated GET to /api/v1/config/, retrieving the plaintext OpenAI (or other LLM provider) API key stored in the running config; they reuse the harvested key to query the victim's LLM backend directly for cost-harvesting or data access, bypassing all application-layer controls. Separately or in the same session, the attacker issues an unauthenticated PUT to /api/v1/config/mem0/llm setting ollama_base_url to http://169.254.169.254/latest/meta-data/iam/security-credentials/<role>, causing the mem0 server to make an internal request to the cloud metadata service on the attacker's behalf; if the response is reflected, logged, or otherwise recoverable, this yields cloud IAM role credentials the attacker can use for lateral movement and further privilege escalation inside the victim's cloud environment.

Weaknesses (CWE)

CWE-306 — Missing Authentication for Critical Function: The product does not perform any authentication for functionality that requires a provable user identity or consumes a significant amount of resources.

  • [Architecture and Design] Divide the software into anonymous, normal, privileged, and administrative areas. Identify which of these areas require a proven user identity, and use a centralized authentication capability. Identify all potential communication channels, or other means of interaction with the software, to ensure that all channels are appropriately protected, including those channels that are assumed to be accessible only by authorized parties. Developers sometimes perform authentication at the primary channel, but open up a secondary channel that is assumed to be private. For example, a login mechanism may be listening on one network port, but after successful authentication, it may open up a second port where it waits for the connection, but avoids authentication because it assumes that only the authenticated party will connect to the port. In general, if the software or protocol allows a single session or user state to persist across multiple connections or channels, authentication and appropriate
  • [Architecture and Design] For any security checks that are performed on the client side, ensure that these checks are duplicated on the server side, in order to avoid CWE-602. Attackers can bypass the client-side checks by modifying values after the checks have been performed, or by changing the client to remove the client-side checks entirely. Then, these modified values would be submitted to the server.

Source: MITRE CWE corpus.

CVSS Vector

CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:L/A:N

Timeline

Published
July 7, 2026
Last Modified
July 20, 2026
First Seen
July 7, 2026

Related Vulnerabilities