Trudesk EUVD-2026-107247

Exploitation requires the attacker to know or guess a valid ticket MongoDB ObjectId and the corresponding attachment filename, then request it directly under /uploads; it works against default configurations because express.static serves the public/ directory before the hasAuth-guarded /uploads route in src/middleware/index.js. No authentication, credentials, or user interaction are required (PR:N/UI:N). The primary limiting factor is the AT:P attack requirement - the unpredictability of the 12-byte ObjectId and filename - so blind mass exploitation is impractical; exploitation is realistic when IDs/filenames leak via URLs, email notifications, or referrers, or against instances where IDs can be enumerated.

This is a genuine information-disclosure risk rather than a hollow high-CVSS number, but it is bounded by one real prerequisite. The supplied CVSS 4.0 vector (AV:N/AC:L/AT:P/PR:N/UI:N) describes a network-reachable, unauthenticated flaw requiring no user interaction, but the AT:P flag encodes a concrete attack requirement: the attacker must know or guess a valid ticket MongoDB ObjectId plus the attachment filename. That single qualifier is what separates this from a trivially scannable mass-exploitation bug. The VC:H/VI:N/VA:N impact correctly reflects a pure confidentiality loss (reading private attachments) with no integrity or availability effect. No EPSS score, no CISA KEV listing, and no confirmed public exploit code were provided in the input, so there is no signal of active or widespread exploitation - meaning priority should be driven by data sensitivity (ticketing systems often hold PII, credentials, internal documents), not by observed in-the-wild activity. Conflict to note: the 'Path Traversal' tag is not supported by the description or CWE-552 - the actual root cause is express.static serving public/ before the hasAuth-guarded /uploads mount (a middleware ordering / missing-authorization issue), not directory traversal; treat the traversal label as unverified.

An attacker who has obtained or can predict a Trudesk ticket's ObjectId and the stored attachment filename (for example from a leaked URL, email notification, or enumeration) sends a direct HTTP request for that file under /uploads. Because express.static resolves the request against the public directory before the hasAuth guard on the /uploads mount ever runs, the server returns the private attachment without any authentication. No public exploit code was identified in the provided data, though a third-party technical write-up describing the issue is referenced.