Podatności mem0

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 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.