Katalog podatności CVE

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.

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

Flowise przed wersją 3.1.3 nie weryfikuje, czy identyfikator subskrypcji Stripe należy do organizacji uwierzytelnionego użytkownika. Uwierzytelniony atakujący może wykonywać nieautoryzowane operacje na subskrypcjach Stripe innych dzierżawców, w tym zmieniać plany lub liczbę miejsc.

Flowise przed wersją 3.1.3 zawiera podatność w endpointcie PUT /api/v1/executions/:id, który nie posiada middleware checkAnyPermission() chroniącego inne endpointy wykonawcze. Każdy uwierzytelniony użytkownik, niezależnie od przypisanych uprawnień, może modyfikować stan, dane i metadane dowolnego wykonania w swoim workspace, co umożliwia eskalację uprawnień i manipulację wynikami przepływów pracy.

CVAT (open source narzędzie do adnotacji wideo i obrazów) w wersjach od 1.6.0 do 2.64.0 zawiera podatność, która pozwala atakującemu z dostępem do zapisu do magazynu chmurowego dodanego do instancji CVAT lub z możliwością dodania nowych magazynów chmurowych na nadpisywanie dowolnych plików w systemie plików serwera. Problem został naprawiony w wersji 2.65.0.

W urządzeniu H3C NX15 V100R017 wykryto podatność polegającą na braku uwierzytelnienia w nieznanej funkcji pliku /api/wizard/networkSetup. Atak może być przeprowadzony zdalnie.

Niekontrolowany element ścieżki wyszukiwania w Kiro CLI przed wersją 2.10.0 w systemie Windows może pozwolić zdalnemu nieuwierzytelnionemu atakującemu na wykonanie dowolnego kodu poprzez złośliwie spreparowany katalog projektu zawierający plik wykonywalny, który omija zabezpieczenia zaufania do obszaru roboczego, gdy lokalny użytkownik uruchomi Kiro CLI w tym katalogu. Aby naprawić problem, użytkownicy powinni zaktualizować do wersji 2.10.0 lub nowszej.

Niekontrolowany element ścieżki wyszukiwania w Kiro IDE przed wersją 1.0.228 w systemie Windows może pozwolić zdalnemu nieuwierzytelnionemu aktorowi na wykonanie dowolnego kodu poprzez złośliwie spreparowany katalog projektu zawierający plik wykonywalny, który omija zabezpieczenia zaufania do obszaru roboczego, gdy lokalny użytkownik otworzy ten katalog.

W Lenovo XClarity Orchestrator (LXCO) 2.2.0 zgłoszono podatność polegającą na nieprawidłowej neutralizacji specjalnych elementów w poleceniach systemu operacyjnego. Uwierzytelniony atakujący może w określonych okolicznościach wykonać dowolne polecenia systemu operacyjnego jako uprzywilejowany użytkownik.

Flowise przed wersją 3.1.3 ma trzy punkty końcowe OAuth2, które wyszukują poświadczenia tylko po identyfikatorze, bez filtra workspaceId. Umożliwia to uwierzytelnionym użytkownikom inicjowanie przepływów OAuth2 dla poświadczeń innych obszarów roboczych, a nieuwierzytelnionym atakującym nadpisywanie tokenów lub odświeżanie tokenów dowolnych poświadczeń.

Flowise przed wersją 3.1.3 nie ogranicza dostępu do historii operacji upsert do konkretnego użytkownika, dzierżawcy lub obszaru roboczego. Odpowiedź z punktu końcowego GET /api/v1/upsert-history może przekraczać 100 MB i zawierać wrażliwe dane konfiguracyjne, w tym ustawienia Vector Store, takie jak adres URL serwera Qdrant i nazwa kolekcji. Brakuje autoryzacji, izolacji oraz limitów, co ujawnia parametry integracji i szczegóły infrastruktury.

Flowise przed wersją 3.1.3 w punktach końcowych openai-assistants-vector-store akceptuje kontrolowany przez klienta parametr poświadczeń i ładuje poświadczenia według identyfikatora bez sprawdzania, czy należą one do obszaru roboczego wywołującego. Uprawnienia trasy assistants:* sprawdzają tylko dostęp do funkcji, a kontroler przekazuje req.query.credential bezpośrednio do usługi, która odszyfrowuje poświadczenia i wywołuje API OpenAI bez sprawdzenia workspaceId. Atakujący znający identyfikator poświadczeń innego obszaru roboczego może użyć klucza OpenAI ofiary, czytać, modyfikować lub usuwać wektory i pliki ofiary, powodować obciążenia na koncie OpenAI ofiary i naruszać granice wielodostępności.

Flowise przed wersją 3.1.3 wstrzykuje $vars do piaskownicy wykonywania kodu bez wymagania uprawnienia variables:view, omijając chroniony API zmiennych. Użytkownik lub klucz API bez uprawnień variables:view może wywołać /api/v1/node-custom-function i otrzymać wszystkie zmienne obszaru roboczego, w tym sekrety.

PDM to menedżer pakietów i zależności dla Pythona. W wersjach do 2.26.9 włącznie, PDM automatycznie ładuje lokalne wtyczki projektu z katalogu .pdm-plugins podczas inicjalizacji, co pozwala plikowi kontrolowanemu przez atakującego w niezaufanym repozytorium na wykonanie dowolnego kodu Pythona przed przetworzeniem jakiegokolwiek polecenia. Dzieje się tak, ponieważ load_plugins() działa podczas Core.init() i dodaje .pdm-plugins przez site.addsitedir(), który przetwarza pliki .pth i natychmiast wykonuje każdą linię zaczynającą się od import, więc kod wykonuje się z uprawnieniami użytkownika wywołującego pdm, a nawet proste polecenie takie jak pdm --version je wyzwala (co ma największy wpływ w CI, automatyzacji i kontekstach uprzywilejowanych).

pdm to menedżer pakietów i zależności dla Pythona. Wersje przed 2.27.0 są podatne na path traversal przez write_to_fs. Funkcja InstallDestination.write_to_fs() w src/pdm/installers/installers.py nadpisuje klasę bazową, aby dodać obsługę dowiązań symbolicznych/twardych, ale zastępuje bezpieczną metodę _path_with_destdir() (która waliduje przez Path.resolve() + is_relative_to()) zwykłym os.path.join() bez walidacji ścieżki. Złośliwy wheel z wpisami traversal może zapisywać dowolne pliki.

Zammad 7.1.0 zawiera uwierzytelnioną podatność na nieprawidłową autoryzację w punkcie końcowym klonowania załączników artykułów biletów.

NVIDIA Dynamo dla systemu Linux zawiera podatność umożliwiającą deserializację niezaufanych danych. Udane wykorzystanie może prowadzić do odmowy usługi i manipulacji danymi.

NVIDIA Dynamo dla systemu Linux zawiera podatność w Rust multimodal media fetcher, która może pozwolić atakującemu na przeprowadzenie ataku typu Server-Side Request Forgery (SSRF). Udane wykorzystanie może prowadzić do ujawnienia informacji.