Podatności 9Router

9Router w wersji przed 0.5.2 traktuje żądania z pętli zwrotnej jako zaufane i zezwala na dostęp do /v1/* bez klucza API. Gdy odwrotne proxy przekierowuje ruch publiczny przez 127.0.0.1, src/dashboardGuard.js błędnie klasyfikuje żądania zewnętrzne jako lokalne, co umożliwia zdalnemu, nieuwierzytelnionemu atakującemu dostęp do API /v1, w tym do /v1/models oraz potencjalne nadużycie skonfigurowanych poświadczeń dostawcy upstream.

9Router w wersji przed 0.5.2 nie zabezpiecza ścieżki /codex, co pozwala zdalnemu, nieuwierzytelnionemu atakującemu ominąć bramę klucza API i wysyłać żądania do /codex/*, które są przepisywane na /api/v1/responses. Atakujący może wykorzystać to do wywoływania zewnętrznych dostawców LLM przy użyciu zapisanych poświadczeń operatora.

W 9Router przed wersją 0.4.80 mechanizm ograniczania prób logowania do panelu administracyjnego opiera się na nagłówku X-Forwarded-For, który może być kontrolowany przez atakującego. Pozwala to na ominięcie limitu 5 nieudanych prób i blokad progresywnych poprzez zmianę wartości tego nagłówka przy każdej próbie logowania.

9router 0.4.59 zawiera łańcuch podatności: domyślne hasło (123456), obejście ograniczenia LOCAL_ONLY przez spreparowany nagłówek Host oraz brak walidacji argumentów w child_process.spawn() przy rejestracji wtyczek MCP. Zdalny, nieuwierzytelniony atakujący może zalogować się przy użyciu domyślnych danych, ominąć ograniczenia sieciowe i zarejestrować złośliwą wtyczkę MCP, co prowadzi do zdalnego wykonania kodu na hoście.

W 9Router w wersjach od 0.2.21 do 0.4.44 użyto zakodowanego na stałe zapasowego sekretu JWT '9router-default-secret-change-me', co pozwala atakującemu na fałszowanie ciasteczka auth_token, gdy zmienna JWT_SECRET nie jest ustawiona. Problem został naprawiony w wersji 0.4.44.

W 9Router w wersjach od 0.4.30 do 0.4.37, middleware w src/proxy.js nie chronił ścieżek /api/cli-tools/* i /api/mcp/*, umożliwiając nieuwierzytelnioną rejestrację wtyczek oraz wykonanie poleceń przez most MCP. Luka została naprawiona w wersji 0.4.37.

9Router w wersji do 0.4.41 zawiera nieuwierzytelnioną podatność na ujawnienie informacji, która pozwala zdalnym atakującym na pobranie kluczy API w postaci jawnego tekstu dla wszystkich podłączonych kont dostawców AI poprzez wysłanie pojedynczego żądania do punktu końcowego /api/usage/stats. Atakujący mogą wykorzystać brakujące oprogramowanie pośredniczące uwierzytelniania na trasie API Next.js, aby uzyskać pełne ciągi kluczy API wraz z liczbą tokenów, podziałem kosztów i metadanymi żądań.

9Router w wersji do 0.4.41 zawiera lukę umożliwiającą nieuwierzytelniony dostęp do API zarządzania dostawcami. Brak middleware uwierzytelniającego w trasach Next.js API (src/app/api/providers/*) pozwala atakującym na wyliczanie, tworzenie, modyfikowanie lub usuwanie połączeń z dostawcami bez żadnych poświadczeń.

W 9Router przed wersją 0.4.80 endpoint /api/settings/database umożliwia pełny eksport bazy danych (zawierającej wszystkie poświadczenia, klucze API, tokeny OAuth i ustawienia) oraz pełny import bazy danych (całkowite nadpisanie) bez żadnego uwierzytelnienia poza sprawdzeniem ALWAYS_PROTECTED, które weryfikuje tylko JWT lub token CLI. Luka została naprawiona w wersji 0.4.80.

9Router przed wersją 0.4.44 zawiera podatność na wstrzykiwanie poleceń systemu operacyjnego w nieuwierzytelnionym punkcie końcowym POST /api/tunnel/tailscale-install. Pole sudoPassword z ciała żądania jest przekazywane do standardowego wejścia procesu 'sudo -S sh', co pozwala zdalnemu, nieuwierzytelnionemu atakującemu na wykonanie dowolnych poleceń systemowych.

Podatność SSRF w trasie POST /api/provider-nodes/validate w 9router pozwala atakującemu na wysyłanie żądań serwerowych do wewnętrznych adresów, w tym loopback i link-local, z powodu błędów w guardzie assertPublicUrl. Dodatkowo odpowiedzi wewnętrzne mogą być ujawniane, a klucz API jest przekazywany do wewnętrznych celów.

9Router w wersji 0.5.4 i wcześniejszych nie ogranicza parametru issuerUrl w endpointcie POST /api/auth/oidc/test, co pozwala nieuwierzytelnionym atakującym (gdy logowanie do panelu jest wyłączone) na skanowanie wewnętrznych usług i odzwierciedlanie pól OIDC discovery, takich jak token_endpoint i jwks_uri.

9Router przed wersją 0.4.72 zawiera podatność Server-Side Request Forgery (SSRF) w endpoint /v1/web/fetch. Endpoint akceptuje kontrolowany przez użytkownika parametr url i przekazuje go do skonfigurowanego zewnętrznego dostawcy skrobania (Firecrawl, Jina Reader, Tavily lub Exa) w celu pobrania treści. URL jest walidowany tylko składniowo przez new URL() bez blokowania prywatnych zakresów IP, endpointów metadanych chmury (np. 169.254.169.254), adresów link-local ani wewnętrznych nazw hostów. Uwierzytelniony lub lokalnie podłączony użytkownik może spowodować, że serwer pobierze dowolne wewnętrzne URL-e i zwróci ich treść, umożliwiając SSRF z dostępem do odczytu, który może ujawnić dane uwierzytelniające chmury, dotrzeć do wewnętrznych usług i ominąć uwierzytelnianie na endpointach localhost.

9Router przed wersją 0.5.2 umożliwia zdalnemu uwierzytelnionemu atakującemu wykonanie dowolnego kodu na systemie operacyjnym. Podatność polega na połączeniu obejścia ograniczeń Host header dla tras localhost z niezweryfikowanymi argumentami wtyczek MCP przekazywanymi do child_process.spawn(), co pozwala na wykonanie komend przez złośliwe wtyczki.

W 9Router przed wersją 0.5.4 endpoint PATCH /api/settings zapisuje całe ciało żądania do ustawień trwałych bez listy dozwolonych pól. Umożliwia to uwierzytelnionemu użytkownikowi ustawienie krytycznych pól bezpieczeństwa, takich jak requireLogin, i wyłączenie uwierzytelniania dla całej aplikacji, co naraża chronione trasy na nieuwierzytelniony dostęp.

W 9Router przed wersją 0.5.6, endpoint walidacji klucza API Kiro (POST /api/oauth/kiro/api-key) konstruuje adres URL upstream na podstawie wartości regionu kontrolowanej przez użytkownika. Umożliwia to uwierzytelnionemu atakującemu przekazanie spreparowanego regionu (np. kiro-canary.local:8443#) i skierowanie żądania walidacji do kontrolowanego przez siebie hosta, jednocześnie przesyłając klucz API Kiro w nagłówku Authorization.

W 9Router w wersji 0.4.45 i wcześniejszych, funkcja isLocalRequest() w src/dashboardGuard.js wykorzystuje nagłówki Host i Origin do ochrony endpointów /api/mcp/*, /api/tunnel/* oraz /api/cli-tools/*. Pozwala to na ominięcie zabezpieczeń poprzez fałszowanie nagłówków w środowiskach reverse proxy lub tuneli, co umożliwia dostęp do ścieżek stdin procesów MCP.

9Router w wersji do 0.4.41 zawiera nieuwierzytelnioną podatność na ujawnienie informacji, która pozwala zdalnym atakującym na dostęp do wrażliwych danych użytkownika poprzez wysyłanie żądań do niechronionych punktów końcowych API. Atakujący mogą wyliczać paginowane logi żądań i pobierać pełne historie konwersacji AI, w tym prompty systemowe, wiadomości użytkowników, odpowiedzi asystenta, wywołania narzędzi i adresy e-mail użytkowników, poprzez zapytania do tras API request-logs i request-details, które nie posiadają middleware uwierzytelniającego.

9Router przed wersją 0.5.2 zawiera podatność polegającą na tym, że decyzja o tym, czy żądanie proxy LLM jest lokalne, podejmowana jest na podstawie kontrolowanego przez klienta nagłówka Host. Zdalny, nieuwierzytelniony atakujący może wysłać nagłówek Host: localhost i ominąć uwierzytelnianie API-key.

9Router przed wersją 0.5.2 zawiera podatność na atak DNS rebinding. Walidacja adresów URL obrazów sprawdza rozpoznawanie DNS przed pobraniem, ale samo pobieranie wykonuje osobne rozpoznawanie, co pozwala atakującemu na przekierowanie żądania do wewnętrznych usług HTTP.