CVE-2026-77293

TREK to wspólny planer podróży. Przed wersją 3.4.0 logika checkSsrf w pliku server/src/utils/ssrfGuard.ts nie rozpoznaje adresów przejściowych IPv6 NAT64, 6to4 lub Teredo, które kodują docelowy adres IPv4. Uwierzytelniony użytkownik kontrolujący rekord DNS może podać URL, którego wynik AAAA jest adresem przejściowym zawierającym prywatny, loopback lub link-local adres IPv4, a isAlwaysBlocked i isPrivateNetwork klasyfikują ten adres jako dozwolony. W środowisku, które routuje odpowiedni format przejściowy, importy, webhooki, integracje lub wyjście wtyczek mogą dotrzeć do usług wewnętrznych lub metadanych chmury i ujawnić zwrócone informacje. Problem naprawiono w wersji 3.4.0.

TREK to wspólny planer podróży. Przed wersją 3.3.0 narzędzie get_trip_summary w pliku server/src/mcp/tools/trips.ts jest zarejestrowane dla tokenów OAuth MCP o ograniczonym zakresie bez wymagania trips:read i zwraca podstawowe dane podsumowania podróży niezależnie od delegowanych zakresów. Token przyznany tylko niepowiązanej zdolności, takiej jak weather:read, może otrzymać metadane podróży, adresy e-mail członków z server/src/services/tripService.ts, dni planu i zakwaterowanie dla każdej podróży dostępnej dla użytkownika tokenu. Autoryzacja między użytkownikami pozostaje egzekwowana, ale brak sprawdzenia zakresu narusza granicę najmniejszych uprawnień i ujawnia treść podróży oraz dane kontaktowe osób trzecich klientowi MCP, który nie był upoważniony do ich odczytu. Problem naprawiono w wersji 3.3.0.

TREK to wspólny planer podróży. Przed wersją 3.3.0 funkcja getSharedTripData w pliku server/src/services/shareService.ts zwraca dni, przypisania, notatki dzienne i miejsca przez GET /api/shared/:token nawet gdy właściciel podróży wyłączy share_map. Klient ukrywa mapę, ale publiczna odpowiedź JSON nadal zawiera plan i nazwy miejsc, współrzędne, adresy, opisy, notatki i ceny. Każdy posiadający ważny token udostępniania może zatem odczytać informacje o lokalizacji i trasie, które właściciel wyraźnie zdecydował się nie udostępniać, chociaż losowy token jest nadal wymagany, a luka nie pozwala na modyfikację. Problem naprawiono w wersji 3.3.0.

TREK, wspólny planer podróży, w wersjach przed 3.3.0 pozwala uwierzytelnionemu użytkownikowi zapisać kontrolowany przez atakującego adres llm_base_url przez API ustawień, gdy funkcja LLM_PARSING jest włączona. Wartość jest używana przez klientów bez zastosowania zabezpieczenia przed SSRF, co przy wywołaniu importu wspomaganego AI powoduje, że serwer wykonuje żądanie do podanego adresu, a tekst odpowiedzi błędu może zostać zwrócony w ostrzeżeniach parsowania. Umożliwia to odkrywanie usług wewnętrznych i dostęp do metadanych chmury link-local, z możliwym ujawnieniem poświadczeń infrastruktury i modyfikacją chronionych zasobów chmury. Luka została naprawiona w wersji 3.3.0.

W liketrek TREK do wersji 3.0.22 występuje podatność w funkcji loginUser w pliku server/src/services/authService.ts, w komponencie Pre-2FA mfa_token Handler. Manipulacja prowadzi do nieprawidłowego uwierzytelnienia. Atak może być przeprowadzony zdalnie. Zalecana jest aktualizacja do wersji 3.1.0.

TREK to narzędzie do planowania podróży. Przed wersją 3.1.3, akcje przesyłania, aktualizacji i linkowania plików w TREK akceptują kontrolowane przez atakującego wartości reservation_id, place_id i assignment_id bez użycia findForeignLinkTarget() do weryfikacji, czy odwoływany obiekt należy do podróży pliku. Uwierzytelniony użytkownik z uprawnieniami do edycji plików w dowolnej dostępnej podróży może przesłać obcy identyfikator rezerwacji przez POST /api/trips/:tripId/files/:id/link, POST /api/trips/:tripId/files lub PUT /api/trips/:tripId/files/:id. Kolejne odczyty przez FILE_SELECT lub getFileLinks() łączą obcą rezerwację i zwracają reservation_title, ujawniając istnienie i tytuły rezerwacji poza granicami prywatnych podróży. Problem został naprawiony w wersji 3.1.3.

TREK to aplikacja do planowania podróży. Od wersji 3.0.0 do 3.1.0 trasa GET /api/journeys/:id/share-link w server/src/routes/journey.ts zwraca wynik getJourneyShareLink() z server/src/services/journeyShareService.ts bez sprawdzenia, czy uwierzytelniony żądający ma dostęp do podróży. Każdy zwykły uwierzytelniony użytkownik może przeglądać sekwencyjne identyfikatory podróży i pobierać tokeny z journey_share_tokens dla podróży innego użytkownika. Token umożliwia nieuwierzytelniony dostęp przez GET /api/public/journey/:token do wpisów, podpisów, lokalizacji, nastrojów, zdjęć galerii, ścieżek zdjęć i identyfikatorów zasobów udostępnionej podróży. Problem naprawiono w wersji 3.1.0.

TREK to aplikacja do planowania podróży. Przed wersją 3.1.0 TREK weryfikuje tylko początkowy URL przed natywnym przekierowaniem w importGoogleList() i importNaverList() w server/src/services/placeService.ts oraz resolveGoogleMapsUrl() w server/src/services/mapsService.ts. Dotknięte funkcje wywołują checkSsrf() z server/src/utils/ssrfGuard.ts, a następnie używają fetch() z redirect: 'follow' zamiast bezpiecznej ścieżki safeFetch() z przypiętym DNS, więc publiczny URL kontrolowany przez atakującego może przekierować serwer na adresy loopback, RFC 1918 lub metadane chmury bez ponownej weryfikacji. Uwierzytelniony członek podróży może uzyskać dostęp do tras importu list, a każdy uwierzytelniony użytkownik może uzyskać dostęp do /api/maps/resolve-url, co pozwala na ślepe żądania GET do wewnętrznych usług bez odbicia treści odpowiedzi. Problem naprawiono w wersji 3.1.0.

TREK przed wersją 3.1.0, gdy włączony jest dodatek Journey, interpoluje nieucieczoną wartość activeSuggestion.title do tekstu sugestii i renderuje ją przez dangerouslySetInnerHTML. Właściciel podróży może przechowywać HTML w tytule, który zostanie wykonany w sesji współpracownika.

W aplikacji TREK przed wersją 3.0.18 wykryto podatność polegającą na różnicy czasu odpowiedzi podczas logowania. Atakujący może wykorzystać tę lukę do enumeracji prawidłowych kont użytkowników, ponieważ brak użytkownika w bazie powoduje natychmiastowy zwrot odpowiedzi (~10 ms), podczas gdy istniejący użytkownik wymaga porównania bcrypt (~370 ms).