Threat Intelligence Database

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 DELETE /api/trips/:tripId/collab/notes/:noteId/files/:fileId endpoint authorizes an authenticated user against the attacker-controlled tripId but deleteNoteFile in server/src/services/collabService.ts 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. Sequential identifiers make broad targeting practical, while attachment read operations remain trip-scoped and are not affected. This issue is fixed in version 3.3.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 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 is a collaborative travel planner. Prior to 3.3.0, TREK allows an authenticated user to store an attacker-controlled llm_base_url through the settings API when the LLM_PARSING feature is enabled. Write permission to the target trip instance is required to trigger the vulnerable AI-assisted import path. The value is consumed by the clients in server/src/nest/llm-parse/clients/openai-compatible.client.ts, server/src/nest/llm-parse/clients/anthropic.client.ts, and server/src/nest/llm-parse/router/ollama-format.client.ts without applying the server-side request forgery guard. Triggering AI-assisted trip parsing causes the server to request the supplied destination, and upstream error response text can be 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. This issue is fixed in version 3.3.0.

CVE-2026-62945 is an authorization bypass vulnerability in mauriceboe TREK prior to version 3.1.3. The issue allows authenticated users with file-edit permissions on any accessible trip to link files to foreign reservations, places, or assignments without proper verification that these objects belong to the trip. This leads to unauthorized disclosure of reservation titles across private trip boundaries. The vulnerability is fixed in version 3.1.3.

CVE-2026-54509 is a missing authorization vulnerability in mauriceboe TREK versions 3.0.0 up to but not including 3.1.0. The GET /api/journeys/:id/share-link endpoint does not verify if the authenticated user has permission to access the requested journey. This allows any authenticated user to enumerate journey IDs and obtain share tokens for other users' journeys. These tokens enable unauthenticated access to shared journey details such as entries, captions, locations, moods, gallery photos, photo paths, and asset identifiers. The issue is resolved in version 3.1.0.

CVE-2026-54508 is a Server-Side Request Forgery (SSRF) vulnerability in mauriceboe TREK, a collaborative travel planner. Versions prior to 3.1.0 improperly validate URLs during certain list import and URL resolution functions, allowing authenticated users to cause the server to make blind GET requests to internal or sensitive network addresses without revalidation. This could enable access to internal services such as loopback, RFC 1918 private addresses, or cloud metadata endpoints. The issue is fixed in version 3.1.0.

CVE-2026-54505 is a cross-site scripting (XSS) vulnerability in the TREK collaborative travel planner prior to version 3.1.0. When the Journey add-on is enabled, unescaped user input from trip titles is rendered directly into the DOM using dangerouslySetInnerHTML, allowing a trip owner to inject HTML that is then displayed to collaborators. Although the default Content Security Policy mitigates script execution, this flaw can enable content spoofing and UI redress attacks. The issue is fixed in version 3.1.0.

TREK is a collaborative travel planner. Prior to 3.0.18, early return on missing user during login flow allowed an attacker to enumerate valid user accounts via response timing discrepancy. When an email address existed in the database, the backend performed a bcrypt password comparison before returning a 401 Unauthorized, adding ~370 ms of latency. When the email did not exist, the backend returned immediately (~10 ms). This ~14× timing difference could be detected without any difference in HTTP status codes or response bodies. This vulnerability is fixed in 3.0.18.