MrDoc EUVD-2026-110841

Requires an authenticated account on the MrDoc instance (PR:L) and a target document that already has a DocShare record. Because the share token is derived deterministically as the MD5 of '{doc_id}_{username}', an attacker who knows or can enumerate the target document's ID and the owner's username can compute the token offline. The vulnerable manage_doc_share type 3 branch then updates the DocShare row filtered only by token (no doc__create_user ownership check), so the attacker can set is_enable=true to re-enable a disabled share or set share_type=0 to remove the access code. Limiting factors: valid authentication is required, the attacker must know/guess the document ID and owner username, and a share record for that document must exist; the flaw does not grant code execution or availability impact.

This is a medium-severity (CVSS 5.3) broken-access-control/IDOR issue (CWE-639), and the available signals point to a genuine but non-urgent problem rather than a high-priority emergency. The CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:L/UI:N/VC:L/VI:L/VA:N) indicates network-reachable, low-complexity exploitation but requires low privileges (PR:L) - i.e. an authenticated account - and yields only limited confidentiality and integrity impact with no availability impact, which is consistent with the description (an authenticated user altering another user's share settings). No EPSS score is provided, the CVE is not in CISA KEV, and no verified exploit code is referenced, so there is no evidence of active exploitation; the only mechanism references are the bug report, the VulnCheck advisory, and the fix commit. The vendor priority label is 'this_month', aligning with the medium severity and the authentication prerequisite. The main real-world constraint is that exploitation requires a valid account on a multi-user instance plus knowledge of the target document ID and owner username; absent those, impact is limited. Net: a legitimate access-control fix to schedule, not a drop-everything issue.

On a multi-user MrDoc instance, a logged-in low-privilege user computes the predictable share token for a colleague's private document as MD5('{doc_id}_{username}'), then invokes the manage_doc_share type 3 branch - which updates by token without checking ownership - to re-enable a previously disabled share and remove its access code. The document is then exposed without the owner's consent. No verified public exploit code is referenced, though the vendor fix commit and VulnCheck advisory describe the flaw in detail.