CVE-2026-77320 in TREK
Summary
by MITRE • 09/24/2026
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.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 09/24/2026
The vulnerability identified in TREK prior to version 3.3.0 represents a significant authorization bypass within the application's data sharing mechanism. As a collaborative travel planner, TREK relies on granular control over shared information to respect user privacy preferences. The core flaw resides in the server-side implementation of the getSharedTripData function located in shareService.ts. When an API request is made via GET /api/shared/:token, the backend logic fails to enforce the trip owner's preference regarding map visibility. Specifically, even when a user explicitly disables the share_map setting, the endpoint continues to return comprehensive itinerary data including days, assignments, day notes, and place details in the JSON response payload.
From a technical perspective, this is an insecure direct object reference combined with insufficient access control logic on the server side. The application correctly validates the presence of a valid share token, ensuring that only individuals possessing the specific identifier can access any data at all. However, it fails to filter or sanitize sensitive fields based on the user's privacy configuration. While the client-side interface appropriately hides the map visualization for users with disabled sharing permissions, this is merely a cosmetic fix. The underlying API endpoint remains vulnerable because it serves raw data regardless of frontend constraints. This discrepancy between server-enforced security and client-rendered presentation allows any authenticated holder of the share token to extract sensitive location intelligence that was intended to remain private.
The operational impact of this vulnerability centers on privacy leakage and potential stalking or surveillance risks. An attacker possessing a valid shared trip link can retrieve detailed route information, specific coordinates, addresses, place names, descriptions, notes, and even pricing data for locations visited by the traveler. This exposure undermines the trust model of collaborative planning tools where users expect that disabling map sharing will prevent location tracking through API responses. Although the vulnerability does not allow for modification or deletion of trip data, preserving integrity, it completely compromises confidentiality regarding geographic movements and personal travel habits.
This issue aligns with CWE-209, which describes an information exposure through an error message, although in this case, it is more accurately categorized under CWE-862, missing authorization, as the server fails to check if the user has permission to view specific data fields before sending them. Furthermore, from a threat modeling perspective using MITRE ATT&CK, this behavior facilitates reconnaissance and collection phases where an adversary gathers sensitive information about targets' movements without detection by standard access controls that only verify token validity rather than field-level permissions.
To mitigate such vulnerabilities, developers must implement strict server-side filtering of response payloads based on user preferences before serialization to JSON. Security checks should occur at the data retrieval layer, ensuring that fields marked as private or restricted are excluded from API responses entirely, not just hidden by client-side CSS or JavaScript logic. Additionally, implementing comprehensive unit tests for edge cases involving privacy settings can prevent regression bugs where new features inadvertently bypass existing security controls. Upgrading to version 3.3.0 resolves this issue by correcting the server-side logic to respect the share_map configuration during data serialization.