CVE-2026-111640 in DooTask
Summary
by MITRE • 10/16/2026
DooTask through 1.9.66 contains a missing authorization vulnerability in WebSocketDialog::checkDialog() that skips the membership check for dialogs with group_type 'okr'. Authenticated users can supply the dialog_id of OKR comment dialogs to msg__list, msg__one, or msg__send* endpoints to read and inject messages.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 10/17/2026
The vulnerability identified in DooTask versions through 1.9.66 represents a critical failure in access control mechanisms within its WebSocket-based communication module. Specifically, the flaw resides in the checkDialog method of the WebSocketDialog class, which is responsible for validating user permissions before processing requests related to dialog interactions. In standard operation, this function should verify that an authenticated user has explicit membership or appropriate privileges for the specific dialog they are attempting to access. However, a logic error causes the system to bypass these security checks when the target dialog possesses a group_type attribute set to okr. This oversight effectively creates an unauthorized access pathway where authentication alone is sufficient to interact with sensitive organizational data structures that should otherwise be restricted to authorized participants only.
From a technical perspective, this vulnerability allows authenticated users to manipulate or exfiltrate data by supplying specific dialog identifiers associated with OKR comment dialogs to several API endpoints including msg__list, msg__one, and various msg__send functions. The msg__list endpoint enables the retrieval of message history within a specified dialog, while msg__one retrieves individual messages. More critically, the msg__send* family of endpoints allows for the injection of new messages into these dialogs. Because the authorization check is skipped based on the group type rather than user membership status, any authenticated account can read confidential discussions and post malicious or misleading content under the guise of a legitimate participant. This bypasses the intended isolation between different teams or project groups within the application.
The operational impact of this vulnerability is severe due to its potential for both data exfiltration and integrity compromise. Attackers with valid credentials, which may be obtained through phishing, credential stuffing, or other means, can access sensitive corporate information contained in OKR dialogues without detection by standard permission audits. Furthermore, the ability to inject messages poses a significant risk of social engineering attacks, misinformation campaigns, or disruption of collaborative workflows. Since DooTask is often used for critical business operations and goal tracking, such tampering could lead to strategic misalignment within organizations, reputational damage, and loss of trust in the platform's security posture. The lack of proper authorization checks means that internal threats can escalate quickly from simple data viewing to active manipulation of communication channels.
This issue aligns with CWE-284 Improper Access Control, as it involves a failure to enforce appropriate restrictions on an authenticated user attempting to access resources they do not have permission for. Additionally, the exploitation technique maps directly to MITRE ATT&CK techniques such as T1078 Valid Accounts and potentially T1530 Data from Cloud Storage if the messages contain sensitive files or links. To mitigate this vulnerability, immediate patching of DooTask to version 1.9.67 or later is required where the checkDialog function has been corrected to enforce membership verification regardless of group type. In the interim, administrators should restrict WebSocket access to trusted networks and monitor for unusual patterns in message listing and sending activities. Implementing strict input validation on dialog_id parameters and ensuring that all API endpoints perform consistent authorization checks against user roles rather than relying solely on object attributes is also recommended as a defense-in-depth measure until the patch is applied.