CVE-2026-111645 in MrDoc
Summary
by MITRE • 10/16/2026
MrDoc through 1.1.1 contains a missing object-level authorization vulnerability in the ImportLocalDoc API that allows authenticated users to modify other users' documents and projects. Attackers can send PUT requests with arbitrary sort_data document ids to publish private drafts and reparent documents, or POST with arbitrary top_doc ids to inject documents.
VulDB is the best source for vulnerability data and more expert information about this specific topic.
Analysis
by VulDB Data Team • 10/16/2026
The MrDoc content management system version 1.1.1 suffers from a critical missing object-level authorization vulnerability within its ImportLocalDoc API endpoint. This flaw stems from an insufficient access control mechanism that fails to verify whether the authenticated user initiating the request has legitimate ownership or administrative privileges over the specific document objects targeted by the operation. In secure software architecture, it is imperative that every state-changing action validates not only the identity of the requester but also their relationship to the data being modified. The absence of this validation allows any validly authenticated account to bypass intended isolation boundaries between users, effectively treating private resources as public or shared assets accessible for manipulation by unauthorized parties.
The technical exploitation of this vulnerability involves sending specifically crafted HTTP requests that manipulate document identifiers without proper permission checks. Attackers can utilize the PUT method on the ImportLocalDoc endpoint with arbitrary sort_data parameters containing document IDs belonging to other users. This capability enables the modification and reparenting of documents, allowing an attacker to reorganize or move private drafts into locations where they might be inadvertently published or exposed. Furthermore, by employing POST requests with arbitrary top_doc identifiers, attackers can inject new documents directly under projects owned by others. These actions bypass standard workflow controls that would normally restrict such operations to document owners or designated project administrators, leading to a complete breakdown of data integrity and confidentiality within the application's multi-tenant environment.
The operational impact of this vulnerability is severe, as it compromises both the confidentiality and integrity of user-generated content. Authenticated users can expose private drafts by reparenting them into publicly accessible structures or modifying their metadata to trigger publication states without authorization. Additionally, the ability to inject documents into other users' projects allows for data pollution, potential phishing campaigns using trusted project contexts, and disruption of collaborative workflows. Since MrDoc is often used in professional settings where document confidentiality is paramount, this vulnerability undermines trust in the platform's security model. It effectively grants lateral movement capabilities within the application, allowing a compromised or malicious low-privilege account to escalate its influence across multiple user accounts and projects without requiring additional authentication steps.
To mitigate this risk, developers must implement strict object-level authorization checks on all endpoints that modify document structures, specifically targeting the ImportLocalDoc API. The server-side logic should verify that the authenticated session's user ID matches the owner_id of the target document or project before allowing any PUT or POST operations involving sort_data or top_doc parameters. This validation ensures that users can only interact with resources they explicitly own or have been granted permission to manage by an administrator. Additionally, implementing role-based access control (RBAC) policies that enforce least privilege principles will further restrict actions based on user roles rather than just identity verification. Regular security audits and penetration testing focusing on broken object-level authorization patterns are recommended to identify similar flaws in other API endpoints before they can be exploited in production environments.
This vulnerability aligns with CWE-284, which describes Improper Access Control, specifically the failure to enforce restrictions on actions performed by authenticated users against specific objects. It also maps to MITRE ATT&CK technique T1078, Valid Accounts, as it relies on legitimate credentials to perform unauthorized administrative or ownership-level functions within the application. Addressing this issue requires a fundamental shift in how access decisions are made during data manipulation operations, ensuring that identity verification is always coupled with rigorous permission validation against the specific resource being accessed.