CVE-2026-45410
MediumCVSS 5.3Exploitation Probability (EPSS)
Low risk11th percentile - higher than 11% of all known CVEs
Summary
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.
Risk Assessment
The risk is remote enumeration of valid user accounts without authentication, enabling targeted attacks such as phishing or brute-force on specific accounts.
Recommendation
Upgrade TREK to version 3.0.18 or later immediately to fix the timing vulnerability.
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-54508Medium
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.
- 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.
Original NVD description (English source)
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.