TREK CVE-2026-77320

Exploitation requires: (1) a self-hosted TREK instance prior to 3.3.0; (2) possession of a valid random share token for a specific trip (the token is unguessable and remains mandatory, which is the primary limiting factor - this is not exploitable by anonymous scanning); and (3) the trip owner having disabled the share_map setting under the false belief it hides location data. The flaw is triggered by requesting GET /api/shared/:token directly instead of using the web UI, since the server-side getSharedTripData never enforces the share_map toggle. Limits: read-only (no modification possible), confidentiality impact limited to itinerary/place metadata, and the audience is restricted to token holders the owner already granted some access to.

This is a genuine but low-severity authorization/information-disclosure flaw, and the signals are internally consistent rather than conflicting. The CVSS 3.1 vector (AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N, base 5.3) correctly captures a network-reachable, low-complexity read-only leak with no integrity or availability impact and only limited confidentiality (C:L). A crucial nuance the PR:N metric understates: exploitation requires possession of the valid random share token, so the realistic attacker is someone the owner already shared the trip with (a former collaborator, or anyone who intercepted/retained the link) rather than an anonymous internet scanner - this is a 'toggle does not enforce' bug where disabling share_map hides the map only in the client while the server JSON keeps returning full itinerary/place data. No EPSS score, no CISA KEV listing, and no public PoC are present in the input, so exploitation status is 'no public exploit identified at time of analysis' - this is not a priority patch candidate. The affected product (TREK, a niche self-hosted OSS travel planner) has a very small footprint, further lowering aggregate risk. Net: a valid privacy/authorization defect worth patching but low real-world risk, not a high-CVSS-but-inflated case - the 5.3 score is honest.

A trip owner turns off the 'share map' option believing location and route details are now hidden, then sends the share link to a collaborator. That collaborator (or anyone who retains the token) requests GET /api/shared/:token directly and reads the raw JSON, which still contains every place name, coordinate, address, note, and price the owner meant to withhold. No public exploit code is required - a single authenticated-by-token HTTP GET returns the data.