TREK EUVD-2026-86339

Requires a valid, already-issued scoped OAuth MCP token for a TREK instance running a version prior to 3.3.0; the token can hold any scope (e.g. weather:read) and does NOT need trips:read, because get_trip_summary was registered without enforcing that scope. Exploitation is limited to trips accessible to the token's own user - cross-user trip authorization remains enforced - so an attacker cannot read arbitrary users' trips, only defeat the intended least-privilege scope boundary for the consenting user's own trips and their collaborators' email addresses. It requires that MCP/OAuth token functionality be deployed and in use.

This is a low-severity, authenticated information-disclosure issue that is a real but low-priority hardening fix rather than a widespread threat. All exploitation signals are modest and mutually consistent: the CVSS 3.1 vector (AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N, base 4.3) requires an already-issued, authenticated OAuth MCP token (PR:L), delivers only limited confidentiality impact (C:L) and no integrity or availability impact. No EPSS score, CISA KEV listing, or public POC was provided, so exploitation status is 'no public exploit identified at time of analysis' - nothing suggests active or automatable mass exploitation. The core weakness is a missing scope check (CWE-200) that defeats the consented least-privilege boundary, but crucially the description confirms cross-user trip authorization is still enforced, so a token cannot reach trips outside its own user. The main risk nuance is third-party exposure: member email addresses of collaborators are leaked to an MCP client the user never authorized for trip data. No data is missing or conflicting; the CVSS vector, description, and CWE all align.

A user connects an MCP client (e.g., a weather add-on) and grants it only a narrow scope such as weather:read. That client - or a malicious/over-curious integration holding the token - invokes get_trip_summary and receives trip metadata, itinerary days, accommodations, and collaborators' email addresses for every trip the user can access, despite never being granted trips:read. No public exploit code is known, and exploitation requires a valid scoped token, so the practical attacker is a rogue or compromised MCP integration rather than an anonymous remote actor.