Podatności LightRAG

LightRAG do wersji 1.5.4 włącznie ma serwer API, który wiąże się ze wszystkimi interfejsami sieciowymi z wyłączonym uwierzytelnianiem domyślnie, co pozwala nieuwierzytelnionemu atakującemu sieciowemu na odczyt indeksowanych dokumentów, przesyłanie lub usuwanie dokumentów, modyfikację grafu wiedzy, anulowanie potoków, czyszczenie pamięci podręcznej i zużywanie zasobów LLM.

W LightRAG przed wersją 1.5.4, gdy zmienna LIGHTRAG_API_KEY jest ustawiona, ale AUTH_ACCOUNTS nie, ochrona za pomocą X-API-Key może zostać ominięta. System używa zakodowanego na stałe tokena DEFAULT_TOKEN_SECRET, a endpointy /auth-status i /login mogą generować gościnne tokeny JWT, które są akceptowane przed sprawdzeniem klucza API. Zdalny, nieuwierzytelniony atakujący może wywoływać chronione endpointy, w tym do odczytu, przesyłania i usuwania dokumentów, mutacji grafu oraz zapytań.

LightRAG w wersji przed 1.5.4 domyślnie konfiguruje CORS z wartością CORS_ORIGINS=* oraz allow_credentials=True, co powoduje, że Starlette CORSMiddleware zezwala na uwierzytelnione żądania z dowolnego źródła. Umożliwia to atakującemu na złośliwej stronie WWW wykonywanie żądań API w imieniu uwierzytelnionego użytkownika.

LightRAG przed wersją 1.4.14 jest podatny na atak polegający na pomyleniu algorytmu JWT, gdzie atakujący może sfałszować tokeny, ustawiając 'alg': 'none' w nagłówku JWT. Funkcja jwt.decode() nie odrzuca jawnie algorytmu 'none', więc sfałszowany token bez podpisu jest akceptowany jako ważny, co prowadzi do nieautoryzowanego dostępu. Podatność została naprawiona w wersji 1.4.14.