TREK — это совместный планировщик путешествий. До версии 3.1.0 TREK проверяет только начальный URL-адрес перед собственным перенаправлением, следующим за импортомGoogleList() и importNaverList() в server/src/services/placeService.ts иsolveGoogleMapsUrl() в server/src/services/mapsService.ts. Затронутые приемники вызывают checkSsrf() из server/src/utils/ssrfGuard.ts, а затем используют fetch() с перенаправлением: 'follow' вместо закрепленного в DNS пути SafeFetch(), поэтому общедоступный URL-адрес, контролируемый злоумышленником, может перенаправить сервер на адреса обратной связи, RFC 1918 или облачные метаданные без повторной проверки.
Участник поездки, прошедший проверку подлинности, может получить доступ к маршрутам импорта списка, а любой прошедший проверку подлинности пользователь может получить доступ к /api/maps/resolve-url, что позволяет выполнять слепые запросы GET к внутренним службам без отражения тела ответа. Эта проблема исправлена в версии 3.1.0.
Показать оригинальное описание (EN)
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.
Характеристики атаки
Последствия
Строка CVSS v4.0