Docmost EUVD-2026-86392

Requires an authenticated low-privileged Docmost user (PR:L) who is a member of the target space and holds edit rights on at least one exportable page in that space. The attacker must embed a forged attachmentId that belongs to a restricted page within the SAME space, and must trigger the page export with the includeAttachments=true option. Limiting factors: exploitation is confined to attachments in a space the attacker can already access (no cross-space or unauthenticated reach), impact is read-only disclosure of attachment content only, and it is fixed in 0.80.1. Affected versions are 0.70.0 through 0.80.0.

This is a genuine but low-severity authorization flaw (CWE-639 IDOR), correctly rated by the CVSS 3.1 vector CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N (base 4.3). The signals are internally consistent and point to a low real-world priority: it requires an authenticated low-privileged account (PR:L) that already holds edit rights on an exportable page in the target space, so it is not a mass-exploitable network flaw despite AV:N. Impact is limited to confidentiality of a subset of attachments (C:L, no integrity or availability impact) - the attacker reads restricted attachment content that direct download would otherwise deny, but only within the same space they can already access as a member. No EPSS score, KEV listing, POC, or SSVC decision data was provided in the input, so there is no evidence of active or automatable exploitation; treat exploitation likelihood as low/targeted. No signals conflict: the CVSS vector, description, and fix commit all agree the vector is network-reachable but privilege- and same-space-constrained. This is a real bug worth patching on the normal cycle, not an emergency.

A low-privileged workspace member who can edit at least one exportable page identifies the attachmentId of a file attached to a restricted page in the same space, then edits their own page to embed that forged attachmentId. They invoke the page export with includeAttachments=true, and the export flow reads the restricted attachment from storage and bundles it into the returned ZIP, disclosing content that direct file download would have denied. No public exploit code was identified in the provided data, though the fix commit reveals the vulnerable export path.