TREK EUVD-2026-86341

Requires an authenticated account with edit access to at least one trip in the TREK collaborative travel planner (the tripId in the path must pass the authorization check, so the attacker needs legitimate edit rights on some trip). No victim interaction is needed. The specific vulnerable path is DELETE /api/trips/:tripId/collab/notes/:noteId/files/:fileId, where deleteNoteFile resolves the target solely by noteId and fileId. Exploitation is limited to note-file attachment DELETION (integrity/availability); attachment read operations remain trip-scoped and are not affected, so no data disclosure is possible. Practicality is enhanced by sequential/predictable identifiers, allowing enumeration and broad cross-trip targeting. Affected on any TREK deployment prior to 3.3.0 in a multi-user/collaborative configuration.

This is a broken-object-level-authorization flaw (CWE-639, IDOR) with a moderately serious real-world profile but no evidence of active exploitation. The CVSS 3.1 vector (AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:H/A:L, base 7.1) indicates network-reachable, low-complexity abuse requiring only low-privilege authenticated access - any user with edit rights to a single trip. No EPSS score, KEV listing, or public POC was provided, so exploitation status is 'no public exploit identified at time of analysis'; the 7.1 is a HIGH-ish score driven entirely by the I:H integrity impact (permanent deletion of other tenants' data) rather than by confirmed exploitation pressure. Confidentiality is untouched (C:N - read operations remain trip-scoped per the description), and availability impact is partial (A:L). The description explicitly notes 'sequential identifiers make broad targeting practical,' which meaningfully raises the practical integrity risk beyond a single-object IDOR - an attacker can enumerate noteId/fileId pairs and mass-delete attachments across unrelated trips. There are no conflicting signals in the data: the CVSS vector, the source-code diff, and the narrative all agree the flaw is a server-side authorization gap where deleteNoteFile resolves the target by note+file id without confirming the file belongs to the authorized trip. Realistic priority: moderate - worth patching promptly for any multi-user TREK deployment, but the niche footprint and lack of exploitation signals keep it below top-tier urgency.

An authenticated TREK user who has edit access to any single trip calls DELETE /api/trips/:tripId/collab/notes/:noteId/files/:fileId, passing their own tripId (which passes the authorization check) but noteId/fileId values belonging to a victim's trip. Because deleteNoteFile validates only the note and file identifiers, the victim's attachment is permanently deleted. Sequential identifiers make it practical to script enumeration and delete attachments across many unrelated trips; no public exploit code was provided.