CVE-2026-77320

TREK is a collaborative travel planner. Prior to 3.4.0, the checkSsrf logic in server/src/utils/ssrfGuard.ts does not recognize NAT64, 6to4, or Teredo IPv6 transition addresses that encode an IPv4 destination. An authenticated user who controls a DNS record can supply a URL whose AAAA result is a transition address embedding a private, loopback, or link-local IPv4 target, and isAlwaysBlocked and isPrivateNetwork classify the address as allowed. In a deployment that routes the applicable transition format, user-facing imports, webhooks, integrations, or plugin egress can reach internal services or cloud metadata and expose returned information. This issue is fixed in version 3.4.0.

TREK is a collaborative travel planner. Prior to 3.3.0, the get_trip_summary tool in server/src/mcp/tools/trips.ts is registered for scoped OAuth MCP tokens without requiring trips:read and returns core trip summary data regardless of the delegated scopes. A token granted only an unrelated capability, such as weather:read, can receive trip metadata, member email addresses from server/src/services/tripService.ts, itinerary days, and accommodations for every trip accessible to the token's user. Cross-user trip authorization remains enforced, but the missing scope check defeats the consented least-privilege boundary and exposes trip content and third-party contact information to an MCP client that was not authorized to read it. This issue is fixed in version 3.3.0.

TREK, a collaborative travel planner, prior to 3.3.0 allows an authenticated user to store an attacker-controlled llm_base_url through the settings API when the LLM_PARSING feature is enabled. The value is consumed by clients without applying the server-side request forgery guard, so triggering AI-assisted trip parsing causes the server to request the supplied destination, with upstream error text returned in parsing warnings. This permits internal service discovery and access to link-local cloud metadata, with possible disclosure of infrastructure credentials and subsequent modification of protected cloud resources. The issue is fixed in version 3.3.0.

TREK, a collaborative travel planner, prior to 3.3.0 contains an authorization flaw in the DELETE /api/trips/:tripId/collab/notes/:noteId/files/:fileId endpoint. The authenticated user is authorized against the attacker-controlled tripId, but deleteNoteFile in the server resolves the target only by note and file identifiers without requiring the file to belong to that trip. A user with edit access to any trip can submit identifiers belonging to another user's trip and permanently delete that note-file attachment.

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.

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.

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.

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.

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.

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.