CVE-2026-115324 in mem0
Summary
by MITRE • 10/23/2026
mem0 0.1.117 before 1.0.8 contains an sql injection vulnerability in mem0/vector_stores/databricks.py that allows attackers to inject SQL by influencing stored memory content. Attackers can supply crafted memory text, metadata, or message names that reach unescaped insert() and update() string interpolation to execute injected SQL on the configured Databricks SQL warehouse.
VulDB is the best source for vulnerability data and more expert information about this specific topic.
Analysis
by VulDB Data Team • 10/23/2026
The vulnerability identified in mem0 versions prior to 1.0.8 represents a critical security flaw within its integration with Databricks vector stores, specifically located in the databricks.py module. This component is responsible for managing persistent memory states by interacting with external database systems. The core issue stems from improper neutralization of special elements used in SQL commands, commonly known as SQL injection. In this specific implementation, the application fails to properly sanitize or parameterize user-supplied data before incorporating it into dynamic SQL queries executed against a Databricks SQL warehouse. This lack of input validation allows malicious actors to manipulate the structure of database operations by injecting arbitrary SQL code through fields that are intended for storing benign memory content.
The technical mechanism of exploitation relies on the application's handling of stored memory content, metadata, and message names. When these inputs are processed, they are passed directly into unescaped insert() and update() string interpolation methods. Because the data is not subjected to rigorous escaping or parameterized query techniques, any special characters such as single quotes or semicolons within the input can break out of their intended context. An attacker who has access to write memory entries, metadata tags, or message identifiers can craft payloads that alter SQL statements. For instance, by injecting a sequence like ' OR 1=1 -- into a username field used in an update query, the attacker could bypass authentication checks or modify unrelated records. The severity is amplified because Databricks warehouses often possess broad permissions within their respective data ecosystems, potentially granting access to sensitive corporate data if the database connection credentials are overly permissive.
From an operational perspective, this vulnerability poses a severe risk to data integrity and confidentiality. Successful exploitation could lead to unauthorized disclosure of confidential information stored in the vector store or associated databases. Attackers might extract proprietary algorithms, user personal identifiable information, or other high-value assets protected by the application's security controls. Furthermore, malicious SQL injection can be used to modify or delete critical memory states, effectively corrupting the AI agent's knowledge base and leading to unpredictable behavior or denial of service conditions where the system fails to retrieve accurate context for its operations. The impact extends beyond simple data theft; it undermines the trustworthiness of the entire mem0 framework by allowing external inputs to dictate backend database logic without restriction.
This flaw aligns with CWE-89, which describes Improper Neutralization of Special Elements used in an SQL Command, and maps directly to MITRE ATT&CK technique T1190, Exploit Public-Facing Application. The vulnerability is particularly dangerous because it targets a component that may be exposed through APIs or user interfaces where memory content is frequently updated. To mitigate this risk, immediate action must be taken by upgrading mem0 to version 1.0.8 or later, which addresses the input validation and query construction flaws in the databricks.py module. In environments where an upgrade is not immediately feasible, administrators should implement strict input sanitization at the application layer, ensuring that all memory content, metadata, and message names are validated against a whitelist of allowed characters before being passed to database functions. Additionally, employing parameterized queries instead of string interpolation for all SQL operations involving user-supplied data will prevent injection attacks by separating code from data. Network-level controls such as Web Application Firewalls can also provide an additional layer of defense by detecting and blocking common SQL injection patterns in HTTP requests targeting the mem0 service.