CVE-2026-77321

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, getSharedTripData in server/src/services/shareService.ts returns days, assignments, dayNotes, and places through GET /api/shared/:token even when the trip owner disables share_map. The client hides the map, but the public JSON response still includes the itinerary and place names, coordinates, addresses, descriptions, notes, and prices. Anyone holding the valid share token can therefore read location and route information that the owner explicitly chose not to share, although the random token remains required and the flaw does not permit modification. 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.