CVE-2026-54508
ŚrednieCVSS 5.3Prawdopodobieństwo exploitacji (EPSS)
Niskie ryzykoPercentyl 24 - wyżej niż 24% wszystkich znanych CVE
Streszczenie
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.
Ocena ryzyka
Podatność umożliwia atak SSRF (Server-Side Request Forgery), co może prowadzić do nieautoryzowanego dostępu do wewnętrznych usług, w tym metadanych chmury, co może skutkować wyciekiem danych lub eskalacją uprawnień.
Rekomendacja
Zaktualizuj TREK do wersji 3.1.0 lub nowszej. Ogranicz dostęp do tras importu list i resolve-url tylko dla zaufanych użytkowników.
Inne podatności w TREK
Zobacz wszystkie- CVE-2026-78863Średnie
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.
- CVE-2026-62945Średnie
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.
- CVE-2026-54509Średnie
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.
- CVE-2026-54505Niskie
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.
- CVE-2026-45410Średnie
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).
Oryginalny opis (angielski, źródło NVD)
TREK is a collaborative travel planner. Prior to 3.1.0, TREK validates only the initial URL before native redirect following in importGoogleList() and importNaverList() in server/src/services/placeService.ts and resolveGoogleMapsUrl() in server/src/services/mapsService.ts. The affected sinks call checkSsrf() from server/src/utils/ssrfGuard.ts and then use fetch() with redirect: 'follow' instead of the DNS-pinned safeFetch() path, so a public attacker-controlled URL can redirect the server to loopback, RFC 1918, or cloud metadata addresses without revalidation. An authenticated trip member can reach the list-import routes, and any authenticated user can reach /api/maps/resolve-url, allowing blind GET requests to internal services without response-body reflection. This issue is fixed in version 3.1.0.