CVE-2026-46339

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.

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.