mem0: SQL injection in Databricks vector store

Summary

mem0 versions 0.1.117 up to 1.0.8 (exclusive) contain an SQL injection flaw in the Databricks vector store backend (mem0/vector_stores/databricks.py). An attacker who can influence stored memory content, such as memory text, metadata or message names, can inject SQL statements that run on the configured Databricks SQL warehouse. The attack only applies if the application uses the Databricks backend and stores untrusted input as memory.

Affected

• mem0 0.1.117 up to, but not including, 1.0.8 (CNA range)
• Affected component: Databricks vector store backend, methods insert() and update()
• Only deployments that use the Databricks vector store are affected

Fixed in

• Upgrade to mem0 1.0.8 or later (fix PR #4558, commit a2ffca32)
• Verify that the deployed build contains commit a2ffca32, because the v1.0.8 release notes do not list #4558
• Later releases (for example Python SDK v2.0.11, which validates Databricks identifiers, #5988) include further hardening; target the current release line

Workaround

• Limit which users, channels or agents can write memories
• Use a least-privilege Databricks identity without write access beyond the memory table
• Review SQL warehouse query logs for unusual statements

These measures are interim suggestions; the vendor advises upgrading.

Exploitation

• No known in-the-wild exploitation; not listed in CISA KEV
• No verified public proof-of-concept exploit found
• The flaw is described openly in the GitHub issue and fix PR, which makes patch-diffing easy
• CISA SSVC: Exploitation none, Automatable no, Technical Impact total

Our recommendation

• Check whether mem0 is used in any lockfile, container image or application, and whether the Databricks backend is configured
• If affected, upgrade to the current mem0 release line and confirm commit a2ffca32 is present
• Restrict who and what can write memory content, and use a least-privilege Databricks identity
• Monitor SQL warehouse logs for unusual statements
• Treat as high priority where Databricks is the backend and untrusted input is stored; otherwise low priority, but still verify the mem0 code

Public exploits iAttack code is publicly available (PoC on GitHub, Metasploit or Exploit-DB).

PoC-in-GitHub, Metasploit and Exploit-DB list nothing for this CVE.

Research sources

• CVE record / VulnCheck advisory www.vulncheck.com
• Fix pull request #4558 github.com
• Fix commit a2ffca32 github.com
• mem0 release v1.0.8 github.com
• Vulnerable file at v1.0.7 github.com
• GitHub issue #4073 github.com
• VulDB entry vuldb.com
• mem0 SDK changelog docs.mem0.ai

Researched and written up in English and German by an AI (Claude by Anthropic) based on NVD, CISA, EPSS and the sources listed. The vendor information is authoritative. Researched on 31 Oct 2026, 04:05.