CVE-2026-31244

Serwer mem0 w wersji 1.0.0 nie posiada kontroli uwierzytelniania i autoryzacji dla swoich punktów końcowych API zarządzania pamięcią. Krytyczne funkcje, takie jak aktualizacja rekordów pamięci, są dostępne bez weryfikacji tożsamości lub uprawnień żądającego.

Komponent openmemory/api w projekcie mem0 zawiera lukę umożliwiającą nieuwierzytelnionym atakującym odczyt, zapis i usuwanie dowolnych pamięci użytkowników poprzez dostęp do routerów API zarejestrowanych bez middleware uwierzytelniającego. Atakujący mogą podać dowolny parametr user_id lub bezpośrednio uzyskać dostęp do punktów końcowych pobierania pamięci, ujawniając prywatne treści, a także wywołać punkty końcowe pauzy z parametrem global_pause=true, powodując odmowę usługi dla wszystkich użytkowników.

Podatność w mem0 ujawnia nieuwierzytelnione endpointy API konfiguracji, które udostępniają klucze API LLM w postaci jawnego tekstu oraz umożliwiają fałszowanie żądań po stronie serwera (SSRF) poprzez kontrolowany przez atakującego parametr ollama_base_url. Nieuwierzytelniony atakujący może pobrać przechowywane sekrety, takie jak klucze API OpenAI, za pomocą żądania GET /api/v1/config/ lub przeprowadzić atak SSRF, ustawiając ollama_base_url na adresy wewnętrzne, np. cloud IMDS, za pomocą żądania PUT /api/v1/config/mem0/llm.

Serwer mem0 w wersji 1.0.0 nie posiada kontroli uwierzytelniania i autoryzacji dla funkcji resetowania pamięci dostępnej przez punkt końcowy DELETE /memories. Nieautoryzowany atakujący może wysłać żądanie DELETE, co prowadzi do wykonania polecenia SQL DROP TABLE, skutkując usunięciem całej tabeli bazy danych pamięci.

Mem0, infrastruktura pamięci trwałej dla agentów AI, w wersjach Python SDK przed 2.0.18 i TypeScript SDK przed 3.1.6 łączy kontrolowane przez wywołującego wartości user_id, agent_id i run_id nieescapowanymi separatorami & i =, co pozwala osadzić inny komponent zakresu w identyfikatorze i uzyskać ten sam klucz session_scope dla różnych dzierżawców. Memory.add(), AsyncMemory.add() oraz REST POST /memories używają tego klucza do odczytu i zapisu surowych wiadomości, umożliwiając ujawnienie rozmów między dzierżawcami oraz usuwanie lub przeplatanie historii innego dzierżawcy.

mem0 w wersji 0.1.117 przed 1.0.8 zawiera podatność na wstrzyknięcie SQL w pliku mem0/vector_stores/databricks.py, która pozwala atakującym wstrzykiwać SQL poprzez wpływ na przechowywaną treść pamięci. Atakujący mogą dostarczać spreparowany tekst pamięci, metadane lub nazwy wiadomości, które trafiają do nieescapowanej interpolacji ciągów w insert() i update(), wykonując wstrzyknięty SQL w skonfigurowanym magazynie Databricks SQL.

Mem0 w wersjach do 0.2.8 zawiera brak autoryzacji w punkcie końcowym POST /configure. Każdy uwierzytelniony użytkownik z kluczem API może zmienić globalną konfigurację LLM i embeddera, przekierowując cały ruch na kontrolowany przez atakującego serwer. Złośliwa konfiguracja jest trwale zapisywana w PostgreSQL i przetrwa restart serwera.

Serwer mem0 1.0.0 nie posiada kontroli uwierzytelniania i autoryzacji dla endpointu API tworzenia pamięci (POST /memories). Endpoint pozwala nieuwierzytelnionym użytkownikom na przesyłanie dowolnych rekordów pamięci bez weryfikacji tożsamości i uprawnień.

Serwer mem0 1.0.0 nie posiada kontroli uwierzytelniania i autoryzacji dla funkcji resetowania pamięci i odtwarzania tabel dostępnych przez endpoint DELETE /memories. Nieuwierzytelniony atakujący może wysłać żądanie DELETE, które uruchamia operację resetowania i wykonanie instrukcji SQL CREATE TABLE.

Serwer mem0 1.0.0 nie posiada mechanizmów uwierzytelniania i autoryzacji dla punktu końcowego API usuwania pamięci (DELETE /memories). Punkt końcowy pozwala nieuwierzytelnionym użytkownikom usuwać rekordy pamięci, podając dowolne identyfikatory użytkowników (np. user_id, run_id, agent_id) w parametrach zapytania. Zdalny atakujący może wysłać nieuwierzytelnione żądania DELETE, aby usunąć dane pamięci dowolnego użytkownika, prowadząc do nieautoryzowanej utraty danych i odmowy usługi.