CVE-2026-54508
MediumCVSS 5.3Exploitation Probability (EPSS)
Low risk24th percentile - higher than 24% of all known CVEs
Summary
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.
Risk Assessment
The vulnerability enables SSRF (Server-Side Request Forgery), which can lead to unauthorized access to internal services, including cloud metadata, potentially resulting in data leakage or privilege escalation.
Recommendation
Update TREK to version 3.1.0 or later. Restrict access to list-import and resolve-url routes to trusted users only.
Other vulnerabilities in TREK
See all- CVE-2026-78863Medium
A vulnerability was found in liketrek TREK up to 3.0.22. It impacts the function loginUser in server/src/services/authService.ts of the Pre-2FA mfa_token Handler component. The manipulation results in improper authentication. The attack may be performed remotely. Upgrading to version 3.1.0 is recommended.
- CVE-2026-62945Medium
TREK is a collaborative travel planner. Prior to 3.1.3, TREK file upload, update, and link actions accept attacker-controlled reservation_id, place_id, and assignment_id values without using findForeignLinkTarget() to verify that the referenced object belongs to the file's trip. An authenticated user with file-edit permission on any accessible trip can submit a foreign reservation identifier through POST /api/trips/:tripId/files/:id/link, POST /api/trips/:tripId/files, or PUT /api/trips/:tripId/files/:id. Subsequent reads through FILE_SELECT or getFileLinks() join the foreign reservation and return reservation_title, disclosing reservation existence and titles across private trip boundaries. This issue is fixed in version 3.1.3.
- CVE-2026-54509Medium
TREK is a collaborative travel planner. From 3.0.0 until 3.1.0, the GET /api/journeys/:id/share-link route in server/src/routes/journey.ts returns the result of getJourneyShareLink() from server/src/services/journeyShareService.ts without checking whether the authenticated requester can access the journey. Any ordinary authenticated user can enumerate sequential journey IDs and retrieve tokens from journey_share_tokens for another user's journey. The token grants unauthenticated access through GET /api/public/journey/:token to the shared journey's entries, captions, locations, moods, gallery photos, photo paths, and asset identifiers. This issue is fixed in version 3.1.0.
- CVE-2026-54505Low
TREK before 3.1.0, when the Journey add-on is enabled, interpolates the unescaped activeSuggestion.title value into suggestion text and renders it with dangerouslySetInnerHTML. A trip owner can store HTML in a title, which is executed in a collaborator's session.
- CVE-2026-45410Medium
In TREK before version 3.0.18, a timing discrepancy during login allows an attacker to enumerate valid user accounts. Missing users cause an immediate response (~10 ms), while existing users trigger a bcrypt comparison (~370 ms), creating a ~14× timing difference detectable without status code or body changes.
Original NVD description (English source)
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.