mem0: SQL-Injection im Databricks-Vector-Store

Zusammenfassung

mem0-Versionen 0.1.117 bis vor 1.0.8 enthalten eine SQL-Injection-Schwachstelle im Databricks-Vector-Store-Backend (mem0/vector_stores/databricks.py). Ein Angreifer, der gespeicherte Memory-Inhalte beeinflussen kann, etwa Memory-Text, Metadaten oder Nachrichtennamen, kann SQL-Anweisungen einschleusen, die auf dem konfigurierten Databricks SQL Warehouse ausgeführt werden. Der Angriff betrifft nur Anwendungen, die das Databricks-Backend verwenden und nicht vertrauenswürdige Eingaben als Memory speichern.

Betroffen

• mem0 0.1.117 bis vor 1.0.8 (Bereich gemäss CNA)
• Betroffene Komponente: Databricks-Vector-Store-Backend, Methoden insert() und update()
• Nur Installationen mit dem Databricks-Vector-Store sind betroffen

Behoben in

• Auf mem0 1.0.8 oder neuer aktualisieren (Fix-PR #4558, Commit a2ffca32)
• Prüfen, ob das eingesetzte Build den Commit a2ffca32 enthält, da die Release-Notes zu v1.0.8 #4558 nicht auflisten
• Spätere Releases (zum Beispiel Python SDK v2.0.11, das Databricks-Bezeichner validiert, #5988) enthalten weitere Härtungen; die aktuelle Release-Linie anvisieren

Umgehung

• Einschränken, welche Benutzer, Kanäle oder Agenten Memories schreiben können
• Eine Databricks-Identität mit minimalen Rechten verwenden, ohne Schreibzugriff über die Memory-Tabelle hinaus
• SQL-Warehouse-Abfrageprotokolle auf ungewöhnliche Anweisungen prüfen

Diese Massnahmen sind provisorische Empfehlungen; der Hersteller empfiehlt ein Update.

Ausnutzung

• Keine bekannte Ausnutzung in freier Wildbahn; nicht im CISA KEV aufgeführt
• Kein verifizierter öffentlicher Proof-of-Concept-Exploit gefunden
• Die Schwachstelle wird im GitHub-Issue und im Fix-PR offen beschrieben, was das Vergleichen von Patches erleichtert
• CISA SSVC: Exploitation none, Automatable no, Technical Impact total

Unsere Empfehlung

• Prüfen, ob mem0 in einer Lockfile, einem Container-Image oder einer Anwendung verwendet wird und ob das Databricks-Backend konfiguriert ist
• Bei Betroffenheit auf die aktuelle mem0-Release-Linie aktualisieren und prüfen, ob der Commit a2ffca32 vorhanden ist
• Einschränken, wer und was Memory-Inhalte schreiben kann, und eine Databricks-Identität mit minimalen Rechten verwenden
• SQL-Warehouse-Protokolle auf ungewöhnliche Anweisungen überwachen
• Hohe Priorität, wenn Databricks das Backend ist und nicht vertrauenswürdige Eingaben gespeichert werden; sonst niedrige Priorität, der mem0-Code sollte dennoch geprüft werden

Öffentliche Exploits iAngriffscode ist öffentlich verfügbar (PoC auf GitHub, Metasploit oder Exploit-DB).

In PoC-in-GitHub, Metasploit und Exploit-DB ist für diese CVE nichts verzeichnet.

Quellen der Recherche

• 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

Recherchiert und auf Deutsch und Englisch aufbereitet von einer KI (Claude von Anthropic) auf Basis von NVD, CISA, EPSS und den genannten Quellen. Massgebend sind die Angaben des Herstellers. Recherche vom 31.10.2026 04:05.