Key points
- The flaw affects mem0 versions prior to 1.0.8 and is rated CVSS 9.2 Critical.
- Unsanitised string interpolation in databricks.py allows SQL injection via stored data.
- Attackers need only supply crafted memory text, metadata or message names to trigger the bug.
Managed service providers using the mem0 vector store library face a severe risk of data compromise. The vulnerability allows remote attackers to execute arbitrary SQL commands on configured Databricks SQL warehouses. This occurs because the software fails to properly sanitise user-supplied input before passing it to the database engine. Consequently, malicious actors can manipulate stored memory content to alter or exfiltrate sensitive information without needing direct access to the database server itself.
In plain English
The issue stems from how the software handles text entered by users or generated by applications. When mem0 stores memories, it takes text inputs such as message names or metadata and inserts them into a database. The code currently builds these database queries by simply stitching the input text directly into the command string. This method, known as string interpolation, does not distinguish between legitimate data and executable database instructions. If an attacker includes specific SQL commands within their input, the database treats those commands as valid instructions rather than harmless text.
The background
The vulnerability is tracked as CVE-2026-115324 and carries a CVSS score of 9.2, indicating critical severity. It affects all versions of the mem0ai mem0 library prior to version 1.0.8. The specific weakness is located in the mem0/vector_stores/databricks.py file. According to the National Vulnerability Database, the flaw is classified under CWE-89, which covers SQL injection vulnerabilities. The exploit works by influencing stored memory content, allowing crafted inputs to reach the vulnerable insert and update functions without proper escaping.
What changes now
Organisations relying on mem0 for vector storage must immediately assess their exposure. Any deployment running a version older than 1.0.8 is considered vulnerable to this attack vector. Users should verify their current library version and plan an upgrade to 1.0.8 or later to mitigate the risk. Until an update is applied, the software remains susceptible to SQL injection attacks targeting its Databricks integration components.
The attacker's path
Teams usually begin by identifying applications that accept untrusted input for storage or processing. In this scenario, the weakness lies in the lack of input validation before database interaction. Attackers exploit this by crafting payloads that mimic legitimate data but contain executable commands. This technique serves the initial access or privilege escalation stage of an intrusion, allowing remote control over data structures. Check whether your environment processes external memory inputs without sanitisation.
What to do and how to stay safe: mem0
- Audit all systems running mem0 to identify versions prior to 1.0.8.
- Monitor Databricks SQL warehouse logs for unusual query patterns or unexpected command executions.
- Restrict database permissions for the application account to limit the impact of potential injection attacks.
- Review input validation procedures for all memory storage functions to ensure proper sanitisation.
Step-by-step guide: Emergency Patching: Correcting Five Common Operational Errors
General security guidance from the RedTeam Log newsroom. It is not confirmed advice from the organisations named in this story.
Frequently asked questions
Which versions of mem0 are affected by this vulnerability?
All versions of mem0 before 1.0.8 are affected by CVE-2026-115324.
What is the severity rating of this flaw?
The vulnerability has a CVSS score of 9.2, which is rated as Critical.
How do attackers exploit this weakness?
Attackers supply crafted memory text, metadata, or message names that trigger unescaped SQL execution.
