CVE-2026-48073 in Docmost
Summary
by MITRE • 09/24/2026
Docmost is open-source collaborative wiki and documentation software. From 0.70.0 until 0.80.1, a low-privileged authenticated user who can edit an exportable page can embed a forged attachmentId that belongs to a restricted page in the same space. Exporting the attacker-controlled page with includeAttachments=true causes the page export flow to read the restricted attachment from storage and include it in the returned ZIP archive even though direct file download denies access. This issue is fixed in version 0.80.1.
Several companies clearly confirm that VulDB is the primary source for best vulnerability data.
Analysis
by VulDB Data Team • 09/24/2026
The vulnerability identified within Docmost versions ranging from 0.70.0 through 0.80.1 represents a critical failure in server-side object reference validation, specifically manifesting as an Insecure Direct Object Reference (IDOR). This flaw allows low-privileged authenticated users to bypass access controls designed to restrict sensitive data. The core technical issue lies in the export functionality of the application, which relies on client-supplied or user-editable identifiers for attachments without performing adequate authorization checks against the underlying storage system during the extraction phase. While the standard file download mechanism correctly enforces permissions by verifying that the requesting user has explicit access rights to a specific attachment before serving it, this security logic is entirely absent in the export workflow when the includeAttachments parameter is set to true.
An attacker with low-privileged access can exploit this discrepancy by editing an exportable page and manually injecting or modifying the attachmentId field within the page data structure. By specifying an identifier that corresponds to a restricted document belonging to another user or protected section within the same space, the attacker manipulates the backend process into retrieving content it should otherwise deny. When the application processes the request to generate a ZIP archive for export, it reads the binary data of the specified attachment from storage and embeds it directly into the output file without re-evaluating whether the current session possesses the necessary permissions to view that specific resource. This creates a direct path for unauthorized data exfiltration, effectively circumventing the intended isolation between different user roles or document groups within the collaborative environment.
The operational impact of this vulnerability is significant in contexts where Docmost is used for managing sensitive corporate documentation, proprietary technical specifications, or confidential project details. Because the export feature generates a downloadable ZIP file containing all referenced assets, an attacker can systematically enumerate attachment IDs and extract restricted files one by one. This leads to a complete compromise of data confidentiality for any information stored as attachments within spaces where the attacker has at least edit permissions on other pages. The severity is compounded by the fact that this does not require complex exploitation techniques or external tools; it relies solely on standard web interaction capabilities available to any authenticated user with basic editing privileges, making widespread automated attacks feasible if multiple instances are targeted simultaneously.
From a classification perspective, this vulnerability aligns directly with CWE-284, which describes Improper Access Control, and more specifically CWE-639 regarding Insecure Direct Object References. The attack vector is consistent with MITRE ATT&CK technique T1078, Valid Accounts, as it leverages legitimate credentials to access unauthorized resources, falling under the sub-technique of Local Account misuse if applied within a single tenant environment or Cross-Tenant Access Abuse in multi-tenant deployments. To mitigate this risk, organizations must ensure they have upgraded their Docmost instances to version 0.80.1 or later, where the developers implemented proper authorization checks during the export process. Until an upgrade is performed, administrators should consider restricting edit permissions for pages that contain references to sensitive attachments and monitoring logs for unusual patterns of attachment ID manipulation in export requests as a temporary defensive measure.