Podatności Open WebUI

Open WebUI w wersjach od 0.9.5 do 0.11.1 nie ponownie stosuje filtrów WEB_FETCH_FILTER_LIST ani kontroli adresów prywatnych przy przekierowaniach HTTP, gdy włączona jest opcja AIOHTTP_CLIENT_ALLOW_REDIRECTS. Uwierzytelniony użytkownik może przekierować żądania do wykluczonych hostów, pętli zwrotnej, sieci prywatnych lub usług metadanych chmury, a następnie wykorzystać wyniki w wyszukiwaniu, przetwarzaniu URL, narzędziach pobierania stron lub przetwarzaniu obrazów czatu. Problem naprawiono w wersji 0.11.1.

Open WebUI w wersjach od 0.10.0 do 0.11.1 zawiera podatność na nieskończoną pętlę w funkcji usuwania wiadomości w backend/open_webui/models/chats.py. Uwierzytelniony użytkownik może utworzyć cykliczne drzewo czatu i usunąć wiadomość, co powoduje zablokowanie pętli żądań serwera i uniemożliwia obsługę żądań innych użytkowników aż do zabicia procesu. Problem naprawiono w wersji 0.11.1.

Open WebUI przed wersją 0.11.1 w punktach końcowych POST /api/v1/retrieval/process/web i POST /api/v1/retrieval/process/web/search traktowało globalnie routowalną klasyfikację adresów Pythona jako dowód, że cel jest zewnętrzny. Uwierzytelniony użytkownik mógł sprawić, że instancja hostowana na platformie Azure pobierze i zwróci treści z adresu 168.63.129.16 (kanał platformy Azure) oraz innych zastrzeżonych zakresów, które standardowa klasyfikacja odrzucała.

Open WebUI od wersji 0.10.0 do 0.11.1 w punkcie końcowym DELETE /api/v1/knowledge/{id}/delete autoryzowało usunięcie względem bazy wiedzy, ale następnie usuwało zewnętrzne połączenie należące do administratora bez osobnej kontroli administratora lub sprawdzenia innych zależnych baz wiedzy. Niebędący administratorem użytkownik z prawem zapisu do jednej zewnętrznej bazy wiedzy mógł usunąć współdzieloną konfigurację instancji i uczynić niedostępnymi wszystkie inne bazy wiedzy korzystające z tego połączenia.

Open WebUI w wersjach od 0.10.0 do 0.11.1 nie sprawdza uprawnień zapisu do folderu przy tworzeniu nowego czatu z podanym folder_id w endpointach POST /api/chat/completions i POST /api/v1/chat/completions. Uwierzytelniony użytkownik, znając identyfikator folderu współdzielonego, może wstrzyknąć czat do folderu, do którego ma tylko odczyt lub brak uprawnień zapisu, co powoduje wyświetlenie wpisu autoryzowanym czytelnikom folderu. Problem naprawiono w wersji 0.11.1.

Open WebUI od wersji 0.9.6 do 0.11.1 w SafePlaywrightURLLoader w backend/open_webui/retrieval/web/utils.py walidowało kontrolowaną przez użytkownika nazwę hosta w Pythonie, a następnie pozwalało przeglądarce Playwright na ponowne jej rozwiązanie w przechwytujących żądania synchroniczne i asynchroniczne. Uwierzytelniony użytkownik kontrolujący autorytatywny DNS mógł zwrócić publiczny adres do walidacji i wewnętrzny adres do przeglądarki, ujawniając odpowiedzi z wewnętrznych usług lub metadanych chmury poprzez wyszukiwanie w sieci lub pobieranie URL.

Open WebUI od wersji 0.8.11 do 0.11.1 w src/lib/components/chat/FileNav/PortPreview.svelte renderowało zawartość portu terminala w iframe sandbox zawierającym zarówno allow-scripts, jak i allow-same-origin. Ponieważ proxy terminala serwuje tę zawartość z pochodzenia Open WebUI, uwierzytelniony użytkownik mający dostęp do współdzielonego serwera terminala mógł umieścić skrypt na podglądanym porcie i przejąć konto ofiary, gdy ofiara otworzyła podgląd.

Open WebUI w wersjach od 0.9.5 do 0.11.1 nie weryfikuje, czy wywołujący użytkownik jest autorem wiadomości w kanale podczas korzystania z endpointu chat completions. Członek kanału może zastąpić wiadomość innego członka, zachowując oryginalnego autora, co zmienia zapis rozmowy bez uzyskiwania dostępu do innych kanałów. Problem naprawiono w wersji 0.11.1.

Open WebUI w wersjach od 0.7.0 do 0.11.1 nie stosuje filtra metadanych w wbudowanym narzędziu wyszukiwania wiedzy, co pozwala uwierzytelnionemu użytkownikowi na wyliczenie identyfikatorów, nazw i opisów niedostępnych baz wiedzy w współdzielonej kolekcji. Tekst dokumentów pozostaje w oddzielnych kolekcjach, ale metadane są ujawniane. Problem naprawiono w wersji 0.11.1.

Open WebUI od wersji 0.6.41 do 0.11.1 w funkcjach get_user_by_oauth_sub i get_user_by_scim_external_id w backend/open_webui/models/users.py używało dopasowania JSON zawierającego, które kompilowało się do dopasowania podciągów SQL LIKE na SQLite. Temat OAuth zawierający znaki specjalne procent lub podkreślenie mógł rozwiązać się do innej zapisanej tożsamości, potencjalnie wybierając konto administratora i wydając atakującemu sesję tego konta; wdrożenia PostgreSQL nie były dotknięte.

Open WebUI w wersjach od 0.6.27 do 0.11.1 nieprawidłowo przechowuje ciasteczka sesji w narzędziach zewnętrznych, co może prowadzić do wycieku ciasteczek sesji użytkownika do operatora innego serwera narzędzi. Gdy wiele serwerów narzędzi jest podłączonych, a sesja lub połączenie OAuth jest przetwarzane jako ostatnie, żądanie do innego serwera może zawierać ciasteczka sesji Open WebUI, umożliwiając przejęcie konta. Problem naprawiono w wersji 0.11.1.

Open WebUI w wersjach od 0.9.0 do 0.11.1 nie unieważnia buforowanego rekordu użytkownika po zmianie roli administratora. Administrator zdegradowany przez zaufany nagłówek lub mapowanie ról OAuth może utrzymać otwarte połączenie Socket.IO i nadal czytać oraz edytować notatki wszystkich użytkowników, dopóki połączenie nie zostanie zamknięte. Problem naprawiono w wersji 0.11.1.

Open WebUI w wersjach od 0.10.0 do 0.11.1 umożliwia uwierzytelnionemu użytkownikowi umieszczenie folderu pod samym sobą lub pod jego podfolderem, tworząc cykl w drzewie folderów. Brak śledzenia odwiedzonych identyfikatorów folderów podczas operacji usuwania i odczytu pozwala na wywołanie żądania, które nieprzerwanie zużywa zasoby CPU i pamięci, aż do naprawy stanu.

Open WebUI w wersjach od 0.9.0 do 0.11.1 przechowuje wartość alert_minutes w zdarzeniach kalendarza bez walidacji typu, a harmonogram porównuje ją numerycznie. Uwierzytelniony użytkownik z uprawnieniami kalendarza może zapisać nienumeryczną wartość, co powoduje wyjątek i przerywa globalny przebieg alertów, tłumiąc przypomnienia wszystkich użytkowników.

W Open WebUI od wersji 0.9.0 do 0.11.1, nieuwierzytelniony punkt końcowy POST /oauth/backchannel-logout pobiera dokument OIDC discovery i klucze podpisujące przed walidacją tokenu wylogowania, co powoduje niepotrzebne żądania sieciowe i blokowanie pętli zdarzeń, umożliwiając atak DoS na pojedynczą instancję.

Open WebUI w wersjach od 0.9.5 do 0.10.0 umożliwia każdemu uwierzytelnionemu użytkownikowi nadpisanie treści wiadomości w kanale, do którego nie należy (w tym kanały prywatne i DM), poprzez wysłanie żądania z prefiksem channel: w chat_id i docelowym message_id. Problem został naprawiony w wersji 0.10.0.

W Open WebUI w wersjach od 0.10.0 do 0.11.0, procedura DELETE /api/v1/folders/{id} w backend/open_webui/routers/folders.py pozwalała użytkownikowi z prawem zapisu do współdzielonego folderu czatu na trwałe usunięcie czatów i wiadomości należących do właściciela folderu. Kontrola autoryzacji nie wymagała własności ani uprawnień administratora, a kaskada usuwania była powiązana z ID właściciela. Współpracownik może zniszczyć poddrzewo właściciela lub wymusić przeniesienie czatów.

Open WebUI w wersjach od 0.9.6 do 0.11.0 ma podatność na atak DoS w ścieżce wyszukiwania wiedzy. Wzorce zawierające metaznaki regex są kompilowane z silnikiem re z backtrackingiem i uruchamiane bez limitu czasu, co pozwala na zablokowanie rdzenia CPU i zatrzymanie pętli zdarzeń. Problem został naprawiony w wersji 0.11.0.

W Open WebUI w wersjach od 0.10.0 do 0.11.0, komponent KatexRenderer.svelte mógł przechowywać i renderować wiadomość czatu, której blok matematyczny powoduje przepełnienie stosu w KaTeX zamiast błędu parsowania. W wyniku błędu, oryginalny kod matematyczny był wstawiany do strony jako HTML przez {@html}, co pozwala na wykonanie skryptu w przeglądarce każdego, kto widzi wiadomość, w tym współdzielone czaty i kanały. Można ukraść token sesji widza, a administrator może stracić konto.

W Open WebUI w wersji 0.10.2 i wcześniejszych, endpointy GET /api/v1/tools/, GET /api/v1/tools/list oraz GET /api/v1/tools/id/{id} zwracały pełny kod źródłowy narzędzi Python uwierzytelnionym użytkownikom niebędącym administratorami z uprawnieniami tylko do odczytu. Pole ToolResponse celowo pomijało źródło i specyfikacje, ale ToolUserResponse zezwalało na dodatkowe pola, a handlery rozprzestrzeniały pełny model narzędzia w odpowiedzi, ponownie ujawniając pominięte pola.

Open WebUI od wersji 0.8.8 do 0.11.0 ma podatność w terminalowej trasie WebSocket (backend/open_webui/routers/terminals.py), która uwierzytelnia własny JWT pierwszej wiadomości i nie stosuje bramki roli użytkownika (get_verified_user) jak w trasach HTTP. Konto z rolą 'pending' (w tym zarejestrowane ale niezatwierdzone lub dezaktywowane z powrotem do 'pending') może otworzyć interaktywną sesję terminala, jeśli skonfigurowano co najmniej jeden serwer terminala i jego uprawnienia obejmują to konto. Poprawka w wersji 0.11.0.

Open WebUI to rozszerzalna, bogata w funkcje i przyjazna dla użytkownika samodzielnie hostowana platforma AI. Od wersji 0.9.0 do 0.11.0 parsowanie powtarzalności automatyzacji w backend/open_webui/utils/automations.py zakotwiczało reguły minutowe i godzinowe na stałej dacie 2000-01-01, a następnie przechodziło do przodu o jeden interwał, aby znaleźć następne uruchomienie. Pojedyncza reguła FREQ=MINUTELY wylicza synchronicznie około ćwierć wieku wystąpień w pętli zdarzeń, która obsługuje również ruch schedulera, HTTP i WebSocket, a scheduler przelicza następne uruchomienie dla każdego zgłoszonego wiersza przy każdym odpytywaniu. Powoduje to wpływ na dostępność dla każdego innego użytkownika instancji. Problem został naprawiony w wersji 0.11.0.

Open WebUI od wersji 0.9.6 do 0.11.0 ma podatność w endpointzie synchronizacji czyszczenia, który autoryzuje zapis do bazy wiedzy w URL, ale działa na identyfikatorach katalogów i plików podanych w ciele żądania bez sprawdzania, czy należą do tej bazy wiedzy. Użytkownik z prawem zapisu do jednej bazy wiedzy może usuwać katalogi i usunąć embeddingi plików z innej bazy wiedzy, co powoduje wypadanie dokumentów z wyników wyszukiwania i psucie czatu z plikami. Poprawka w wersji 0.11.0.

Open WebUI w wersjach od 0.8.8 do przed 0.11.0 akceptuje załączniki wiedzy dostarczane przez klienta bez filtrowania ich pod kątem praw dostępu do odczytu. Uwierzytelniony użytkownik, znając identyfikator pliku innego użytkownika, może uzyskać dostęp do indeksowanych fragmentów tego pliku, co prowadzi do utraty poufności między użytkownikami. Wersja 0.11.0 naprawia problem.

Open WebUI przed wersją 0.11.0 ma podatność polegającą na tym, że podczas walidacji URL rozwiązywano nazwę hosta i odrzucano adresy prywatne, pętlowe i link-local, ale klienci HTTP ponownie rozwiązywali nazwę hosta w momencie połączenia. Uwierzytelniony atakujący kontrolujący autorytatywny DNS dla zgłoszonej nazwy hosta może odpowiedzieć publicznym adresem podczas walidacji i wewnętrznym podczas połączenia, docierając do metadanych chmury, pętlowych API administracyjnych lub usług wewnętrznych przez URL ingest, pobieranie obrazów czatu, edycję obrazów lub pobieranie zdjęć profilowych OAuth, przy czym większość ścieżek zwraca odpowiedź atakującemu, a ścieżka OAuth przekazuje token dostępu OAuth. Poprawka w wersji 0.11.0.

Open WebUI od wersji 0.9.0 do 0.11.0 zawiera podatność w podglądzie plików terminala, gdzie gałąź iframe dla plików HTML zawsze nadaje uprawnienia allow-same-origin i allow-scripts. Uwierzytelniony użytkownik z dostępem do skonfigurowanego serwera terminala może uruchomić skrypt w kontekście Open WebUI, ukraść token sesji ofiary i przejąć konto, a w przypadku administratora uzyskać możliwość wykonania kodu po stronie serwera.

Open WebUI od wersji 0.9.0 do 0.11.0 sprawdzał, czy adres URL dostarczony przez użytkownika jest globalnie routowalny, stosując ipaddress.is_global do dosłownego adresu IPv6 bez badania adresów IPv4 osadzonych w kodowaniach przejściowych. Wdrożenie z bramą NAT64 pozwala zweryfikowanemu użytkownikowi opakować wewnętrzny adres IPv4 lub adres metadanych chmury w dobrze znany prefiks NAT64, przejść filtr i otrzymać treść odpowiedzi wewnętrznej przez RAG URL ingestion, konwersję URL do markdown lub pobieranie treści z wyszukiwarki.

Podatność w Open WebUI od wersji 0.7.0 do 0.11.0 pozwala uwierzytelnionemu użytkownikowi, któremu odebrano uprawnienie do generowania obrazów, nadal korzystać z tej funkcji przez starsze endpointy czatu. Pomimo blokady flagi image_generation, system nie weryfikował ponownie uprawnień, co umożliwiało nieautoryzowane użycie skonfigurowanego dostawcy obrazów.

Open WebUI w wersjach od 0.9.6 do 0.11.0 umożliwia uwierzytelnionemu użytkownikowi anulowanie zadań (np. generowania odpowiedzi modelu) innego użytkownika, znając jego identyfikator czatu. Dzieje się tak, ponieważ operacja usuwania czatu anuluje zadania przed sprawdzeniem uprawnień do usunięcia. Luka została naprawiona w wersji 0.11.0.

Open WebUI od wersji 0.8.0 do 0.11.0 zawiera podatność w mechanizmie wymiany tokenów OAuth. Gdy ENABLE_OAUTH_TOKEN_EXCHANGE=True, endpoint /oauth/{provider}/token/exchange akceptuje surowy token dostępu i waliduje go bez potwierdzenia, dla którego klienta OAuth został wydany. Każdy posiadacz tokenu wydanego dla dowolnej aplikacji zarejestrowanej u tego samego dostawcy może wymienić go na sesję Open WebUI jako ten użytkownik.

Open WebUI to rozszerzalna, bogata w funkcje i przyjazna dla użytkownika samodzielnie hostowana platforma AI. Od wersji 0.5.0 do 0.11.0 standardowe procedury obsługi aktualizacji i usuwania wiadomości na kanale akceptowały każdego wywołującego z prawem zapisu na kanale, bez sprawdzania, czy wywołujący napisał wiadomość. Ponieważ prawo zapisu jest tym samym uprawnieniem, które członek potrzebuje do publikowania, każdy zwykły uczestnik współdzielonego standardowego kanału mógł przepisać lub trwale usunąć wiadomość innego uczestnika, podczas gdy procedury obsługi wiadomości grupowych i bezpośrednich egzekwowały autorstwo. Problem został naprawiony w wersji 0.11.0.

Open WebUI od wersji 0.6.34 do 0.11.0 renderuje bloki kodu vega i vega-lite w treści czatu, budując widok Vega w przeglądarce bez ograniczonego modułu ładującego zasoby. Użytkownik, który umieści taki blok, może sprawić, że przeglądarka innego użytkownika wyśle żądania GET wybrane przez atakującego i odczyta odpowiedzi z celów samego pochodzenia lub dozwolonych przez CORS.

Open WebUI od wersji 0.9.6 do 0.11.0, przy użyciu silnika WEB_LOADER_ENGINE=playwright, waliduje tylko żądanie najwyższego poziomu, pozwalając na niezweryfikowane żądania podrzędnych zasobów. Strona dostarczona przez uwierzytelnionego użytkownika może użyć JavaScript do uzyskania dostępu do zablokowanych wewnętrznych adresów, a zwrócony DOM może zawierać dane z tych adresów w wynikach wyszukiwania lub RAG.

Podatność w open-webui przed wersją 0.3.14 wynika z błędnej konfiguracji CORS, która zezwala na żądania z dowolnych źródeł (allow_origins=*) oraz uwierzytelnione żądania do endpointu /api/v1/functions. Atakujący może wykonać dowolny kod na instancji open-webui poprzez spreparowane żądania cross-site, gdy administrator odwiedza złośliwą stronę.

Open WebUI przed wersją 0.9.5 zawiera podatność na trwałe ataki XSS w przepływie uwierzytelniania OAuth. Typ MIME adresu URL obrazka profilowego jest określany na podstawie rozszerzenia pliku, a nie nagłówka Content-Type, co pozwala na ominięcie walidatora obrazów i przechowywanie plików SVG jako danych URI. Uwierzytelnieni użytkownicy odwiedzający endpoint obrazka profilowego otrzymują kontrolowaną przez atakującego treść SVG, co umożliwia wykonanie skryptów w tym samym originie, kradzież tokenów uwierzytelniających i przejęcie konta.

Podatność w Open WebUI przed wersją 0.10.0 pozwala na obejście normalizacji ścieżki proxy poprzez dziewięciokrotne zakodowanie sekwencji '../' w formacie percent-encoded. Funkcja _sanitize_proxy_path dekoduje ścieżki tylko osiem razy, co umożliwia atakującemu dostęp do plików poza dozwolonym katalogiem.

Podatność w Open WebUI od wersji 0.6.16 do 0.10.0 pozwala nieuwierzytelnionym atakującym na manipulację stanem współpracy nad dokumentami przez Socket.IO. Serwer Socket.IO był skonfigurowany z always_connect=True, a handlery ydoc:awareness:update i ydoc:document:leave nie wymagały uwierzytelnienia.

W Open WebUI od wersji 0.8.11 do 0.10.0, endpoint POST /api/v1/images/edit wymagał jedynie zweryfikowanego konta, ale nie sprawdzał globalnego przełącznika edycji obrazów ani uprawnień użytkownika do generowania obrazów. Umożliwiało to nieuprawnionemu użytkownikowi wywołanie edycji obrazów po stronie serwera z użyciem poświadczeń dostawcy skonfigurowanych przez administratora.

Podatność w Open WebUI w wersjach od 0.9.0 do 0.10.0 pozwala dezaktywowanym użytkownikom na kontynuowanie zaplanowanego wykonywania modeli. Funkcja execute_automation przywracała właścicieli automatyzacji bez ponownego sprawdzania ich aktywności, a check_model_access egzekwowała ograniczenia tylko dla dokładnej roli użytkownika.

W Open WebUI od wersji 0.8.12 przed 0.10.0, uwierzytelniony niebędący administratorem użytkownik z dostępem do modelu typu arena może ominąć kontrolę dostępu do bazowego modelu poprzez endpointy zadań, takie jak /api/v1/tasks/moa/completions. Normalna ścieżka czatu sprawdza model arena przed wysłaniem zapytania, natomiast ścieżka zadań wywołuje bezpośrednio funkcję generate_chat_completion() z parametrem bypass_filter=True, pomijając kontrolę dostępu do wybranego podmodelu.

Podatność w Open WebUI przed wersją 0.10.0 umożliwia atakującemu wstrzyknięcie zapytania do konstrukcji URL terminala WebSocket, co pozwala na podszycie się pod innego użytkownika. Dodatkowo, nagłówek X-User-Id w proxy HTTP nie był odpowiednio weryfikowany, co ułatwiało manipulację tożsamością.

W Open WebUI przed wersją 0.10.0 mechanizm filtrowania WEB_FETCH_FILTER_LIST porównywał skonfigurowane wpisy hostów z ciągami URL, co pozwalało na ominięcie blokady poprzez umieszczenie adresu w ścieżce URL (np. !internal.example.com) oraz dopasowanie domen pokrewnych, niezgodne z zamierzoną polityką nazw hostów.

Podatność w Open WebUI w wersjach od 0.7.0 do 0.10.0 umożliwia zwykłemu uczestnikowi kanału pobranie wrażliwych ustawień innych użytkowników, w tym kluczy API i konfiguracji webhooków, poprzez żądanie GET /api/v1/channels//members. Problem został naprawiony w wersji 0.10.0.

Podatność w Open WebUI przed wersją 0.10.0 pozwalała na atak typu ReDoS (Regular Expression Denial of Service) poprzez wysłanie specjalnie spreparowanej wiadomości czatu zawierającej sekwencję <$ bez zamykającego >. Wyrażenia regularne SKILL_MENTION_RE i strip_re w pliku backend/open_webui/utils/middleware.py powodowały kwadratowe cofanie (backtracking), blokując pętlę zdarzeń asyncio.

W Open WebUI przed wersją 0.10.0, przy skonfigurowanym Redis, uwierzytelnianie połączeń czasu rzeczywistego (Socket.IO, WebSocket) używało funkcji decode_token bez sprawdzania unieważnienia tokena w Redis. Umożliwiało to uwierzytelnianie przy użyciu unieważnionych JWT.

W Open WebUI przed wersją 0.10.0 endpoint /api/v1/auths/signin umożliwiał wyliczenie istniejących kont poprzez pomiar czasu odpowiedzi. Zapytania dla zarejestrowanych użytkowników były wolniejsze (z powodu weryfikacji bcrypt) niż dla nieistniejących adresów email, co pozwalało nieuwierzytelnionemu atakującemu na enumerację kont.

W Open WebUI przed wersją 0.10.0 ścieżka przesyłania plików akceptowała parametr metadata.knowledge_id i automatycznie łączyła przesłane pliki z docelową bazą wiedzy bez sprawdzania uprawnień do zapisu, co pozwalało użytkownikom z dostępem tylko do odczytu na dodawanie dowolnych plików.

Podatność w Open WebUI przed wersją 0.10.0 pozwala uwierzytelnionym użytkownikom na wykonanie kodu Python lub narzędzi w sesji innego użytkownika. Atakujący może wykorzystać zdarzenia Socket.IO, aby przejąć kontrolę nad sesją ofiary po poznaniu jej identyfikatora gniazda.

W Open WebUI przed wersją 0.10.0 stwierdzono podatność polegającą na braku weryfikacji, czy identyfikator wątku (parent_id) należy do kanału wskazanego w URL. Umożliwia to uwierzytelnionemu użytkownikowi odwołanie się do wiadomości z innego prywatnego kanału lub kanału DM i ujawnienie kontekstu wątku między kanałami.

Open WebUI przed wersją 0.10.0 uruchamia kod Python po stronie klienta w Pyodide w web workerze tego samego pochodzenia, co pozwala na przechowywanie złośliwych ładunków czatu wykorzystujących pyodide.http.pyfetch lub API fetch i XMLHttpRequest z modułu js. Gdy ofiara kliknie „Uruchom”, wysyłane są uwierzytelnione żądania do tego samego pochodzenia, które mogą dotrzeć do punktów końcowych dostępnych tylko dla administratora i wykonać kod po stronie serwera przez skonfigurowane narzędzia.