On this page (7 sections)

A critical SQL injection flaw, tracked as CVE-2026-115324, affects the Databricks vector store code in the mem0ai Python package. According to the GitHub advisory, attackers who can influence stored memory content can cause injected SQL to run on the Databricks SQL warehouse the application is configured to use.

If you build AI assistants or agents on mem0 and store memories in Databricks, this applies to you. Applications using other vector stores are not covered by the advisory text. The fix is in version 1.0.8.

What happened

The advisory was published on October 22, 2026 and updated on October 23, 2026. It describes an SQL injection in mem0/vector_stores/databricks.py. Values that reach the insert() and update() functions are placed into SQL strings through unescaped string interpolation, so specially crafted input can change the query that gets sent to the warehouse.

The advisory names three kinds of attacker-influenced input: memory text, metadata, and message names. Only one independent publisher covers this story so far, so details beyond the advisory and its linked references are limited.

Why this weakness matters

SQL injection happens when an application builds a query by gluing text together instead of passing values as separate parameters. The database cannot tell which part is the developer's query and which part is data, so attacker-supplied text can become part of the command.

What makes this case notable is the input source. In an agent or chatbot, memory content often comes from conversations with users or from documents the model has read. Anyone who can talk to your assistant, or get text in front of it, may be able to influence what is written to memory. That makes the memory layer an input path that needs the same care as a web form.

The CVSS v4 metrics in the advisory list network attack vector, no privileges required, no user interaction, and high attack complexity with attack requirements present. Impact on the vulnerable system is rated high for confidentiality, integrity and availability. The attack requirements and complexity ratings suggest exploitation depends on how the deployment is set up, but the advisory does not spell out those conditions.

Who is affected

  • Projects that install mem0ai from pip at a version from 0.1.117 up to, but not including, 1.0.8.
  • Deployments that configure the Databricks vector store. The vulnerable code is in the Databricks module, and the advisory describes execution on the configured Databricks SQL warehouse.
  • Applications where untrusted users, documents or tool outputs can end up as memory text, metadata or message names.

Impact depends on what the warehouse credentials used by your application can reach. If that identity can read or modify tables beyond the memory store, the blast radius is larger. This is an inference from how SQL injection generally works, not a statement from the advisory.

How to check your exposure

Run this in the Python environment your application uses. It prints the installed mem0ai version; anything from 0.1.117 to 1.0.7 is in the affected range.

Show the installed mem0ai version (run inside your app's virtual environment or container)Shell
pip show mem0ai

If you use a requirements file or lock file, search it for the pinned version so you catch images and CI builds that have not been rebuilt.

Find mem0ai pins in dependency files (run from your project root)Shell
grep -rn "mem0ai" requirements*.txt pyproject.toml poetry.lock Pipfile.lock 2>/dev/null

Then confirm whether your configuration selects Databricks as the vector store. If you use a different store, the advisory does not describe you as affected, but upgrading is still sensible.

What to do now

Caution. Upgrading a dependency changes your application. Test in staging first, then restart the service or redeploy so the new version is actually loaded.

This command upgrades the package to the first fixed release. Run it in the same environment as your application, then restart the app.

Upgrade mem0ai to the fixed versionShell
pip install "mem0ai>=1.0.8"
Tip. If you cannot upgrade immediately, one reasonable stopgap is to disable the Databricks vector store in affected deployments or restrict who can write to memory. The advisory does not list an official workaround, so treat this as general risk reduction, not a fix.

Detection and monitoring

The advisory does not publish indicators of compromise, so detection relies on your own logs. On the Databricks side, look at query history for statements issued by the application's identity that do not match the normal insert and update patterns, such as unusual clauses, queries against other tables, or sudden spikes in volume.

On the application side, log and review rejected or malformed memory writes, and watch for memory entries with unusual quoting or SQL-like text. Add the package to automated dependency scanning so the next advisory reaches you quickly. For the web-facing parts of your stack, Webforta's free security headers checker and monitoring can help you spot unrelated configuration drift, though they do not detect this library flaw.

Timeline and references

  • October 22, 2026: advisory published to the GitHub Advisory Database, with the NVD record for CVE-2026-115324 published the same day.
  • October 23, 2026: advisory reviewed and last updated.
  • Fix released in mem0ai 1.0.8.

For primary details, see the GitHub advisory, the 1.0.8 release notes, the fix commit, pull request 4558 and the VulnCheck advisory. For more on keeping the rest of your stack in good shape, see our small business website security guide.

Sources

This article is based on the public sources below. Details can change as vendors and researchers publish more; check the original advisories before acting on version numbers.

  1. CVE-2026-115324 - GitHub Advisory Databasegithub.com
  • mem0
  • SQL injection
  • Databricks
  • Python
  • CVE-2026-115324
  • AI security