Executive brief
TREK is a collaborative travel planning application. Before version 3.1.0, the application fails to re-validate URLs after HTTP redirects when importing map data or resolving map URLs, allowing attackers to bypass security checks. An authenticated user could trick the server into making requests to internal services (on private networks or cloud metadata endpoints) that should be inaccessible, potentially exposing sensitive configuration or cloud credentials.
Technical details
The vulnerability is a Server-Side Request Forgery (SSRF) via incomplete URL validation in importGoogleList(), importNaverList() (in placeService.ts), and resolveGoogleMapsUrl() (in mapsService.ts). These functions validate the initial URL with checkSsrf() but then use fetch() with redirect: 'follow' instead of the DNS-pinned safeFetch() path, allowing an attacker-controlled public URL to redirect the server to loopback, RFC 1918 private, or cloud metadata addresses without re-validation. Trip members can reach list-import routes; any authenticated user can reach /api/maps/resolve-url, enabling blind GET requests to internal services. The fix in version 3.1.0 enforces safer redirect handling. Authentication is required; network access to the application is necessary.
Affected products
- TREK TREK prior to 3.1.0
Timeline
- 2026-08-20: disclosed
- 2026-06-16: patched: Fixed in version 3.1.0