Docmost EUVD-2026-86389

Requires a Docmost deployment (prior to 0.80.1) using the local filesystem storage driver, since the flaw resolves attacker-controlled fileName segments against local storage; instances backed by external/object storage are not the target described. Exploitation is unauthenticated and remote against the public avatar/logo image endpoint with no user interaction, but disclosure is limited to local-storage objects whose final basename satisfies the route's UUID check - arbitrary system files not matching that UUID pattern cannot be read, which caps confidentiality impact.

This is a genuine but modest-severity issue. The CVSS 3.1 vector (AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N, base 5.3) reflects an unauthenticated, network-reachable, low-complexity read-only information disclosure with limited confidentiality impact and no integrity or availability effect. No EPSS score, no CISA KEV listing, and no public proof-of-concept were provided, so exploitation status is 'no public exploit identified at time of analysis' - there is no evidence of active or automated exploitation. The C:L rating is well-justified by the description itself: the route enforces a UUID check on the final basename, so an attacker cannot read arbitrary paths, only local-storage objects whose filename satisfies that UUID pattern. This significantly constrains what can be exfiltrated (primarily other stored image/attachment objects rather than /etc/passwd or app secrets), making it a real-but-bounded traversal rather than a full arbitrary-file-read. No signals conflict; all point to a low-priority, patch-in-normal-cycle finding rather than an emergency. Note the public patch commit diff is dominated by unrelated dependency bumps and refactors - the actionable fix is the single sanitize-filename guard added in attachment.controller.ts.

An unauthenticated attacker sends a crafted request to Docmost's public avatar/logo image endpoint with path-traversal sequences in the fileName segment, causing the server to resolve a path outside the intended avatar/logo directory against local storage. Because the route still validates that the final basename matches a UUID, the attacker can retrieve other locally stored objects whose filename fits that pattern, disclosing content not meant for that endpoint. No public proof-of-concept is available, but the low attack complexity and lack of authentication make crafting the request straightforward.