CVE-2026-85709

LightRAG przed wersją 1.5.5 renderuje treść odpowiedzi i myślenia za pomocą react-markdown, rehypeRaw i skipHtml=false bez sanityzacji HTML. Atakujący mogący dodać dokument może zapisać surowy HTML, który jest zwracany przez ścieżkę zapytania i renderowany jako aktywna treść, umożliwiając wykonanie dowolnego kodu JavaScript m.in. przez iframe srcdoc. Skrypt działa w origin LightRAG WebUI i może odczytać token API z localStorage oraz wykonywać akcje API w imieniu ofiary.

LightRAG przed wersją 1.5.5 zawiera podatność w parserze Markdown, która umożliwia pobieranie zasobów z wewnętrznych adresów IPv4 przy użyciu translatorów NAT64, co może prowadzić do nieautoryzowanego dostępu do wewnętrznych zasobów.

LightRAG przed wersją 1.5.5 w funkcji verify_password w lightrag/api/passwords.py porównuje hasła AUTH_ACCOUNTS za pomocą operatora ==, co może ujawniać różnice czasowe zależne od długości hasła i pasujących prefiksów. Atakujący sieciowy o niskich opóźnieniach może wielokrotnie odpytywać /login i wykorzystać oracle czasowy do odzyskania hasła znak po znaku. Wdrożenia używające haseł z prefiksem bcrypt nie są dotknięte tą ścieżką porównania.

LightRAG to narzędzie do szybkiego generowania wspomaganego wyszukiwaniem. Przed wersją 1.5.5 endpoint POST /login w lightrag/api/lightrag_server.py nie nakłada limitu szybkości, blokady konta, opóźnienia ani licznika nieudanych prób uwierzytelnienia. Atakujący w sieci może zgadywać hasła z pełną szybkością żądań, aż znajdzie prawidłowe hasło konta.

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.