CVE-2026-77320: TREK: Public trip share link ignores the `share_map` permission server-side (client-enforced authorization → itinerary/location disclosure)
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 sharemap. 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.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
TREKto a version that resolves this vulnerability.Fixed in 3.3.0
Event History
Frequently Asked Questions
Who can access the information exposed by this issue?
Anyone who possesses a valid public trip share token can retrieve the shared trip data. No authentication or additional privileges are required, but the random token is still required.
What information may be disclosed?
The public response can include itinerary days, assignments, day notes, and place data such as names, coordinates, addresses, descriptions, notes, and prices. The issue does not allow trip modification.
Are trips affected when map sharing is disabled?
Yes. In affected versions, disabling share_map only hides the map in the client; the server still returns the underlying itinerary and location data from the public shared-trip endpoint.
Which versions are affected and what is the remediation?
TREK versions prior to 3.3.0 are affected. Upgrade to version 3.3.0, which fixes the server-side permission enforcement.