CVE-2026-77923 in Dolibarr
Summary
by MITRE • 08/24/2026
Dolibarr 21.0.0 before 24.0.0 contains an authorization bypass vulnerability caused by an inverted boolean condition in the private-project membership check within the clonetasks mass action handler in htdocs/core/actions_massactions.inc.php. Authenticated users with project creation permission but without access to a target private project can exploit the flawed !in_array() check to clone tasks into unauthorized private projects.
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 08/24/2026
The vulnerability identified in Dolibarr versions prior to 24.0.0 represents a critical authorization bypass flaw rooted in logic errors within the application's mass action processing module. Specifically, the defect resides in the file htdocs/core/actions_massactions.inc.php, which handles bulk operations for various entities including tasks. The core issue is an inverted boolean condition during the verification of user membership or access rights relative to a target private project. When an authenticated user initiates a clone task operation targeting a specific project ID, the system performs a check to ensure the user has appropriate permissions for that destination context. However, due to the logical inversion in the !in_array() function used to validate this relationship, the security control fails to reject unauthorized access attempts effectively. This means that instead of blocking actions where the user is not part of the project's authorized group or member list, the system erroneously permits them under certain conditions, particularly when combined with other permission checks like general project creation rights.
From a technical perspective, this flaw allows authenticated users who possess the standard permission to create new projects but lack specific access privileges for private projects to exploit the logic gap. By manipulating the parameters sent during the clone task mass action, an attacker can force the system to duplicate tasks from accessible public or shared contexts into private projects where they have no legitimate standing. The inversion of the boolean check means that if a user is not found in the array of authorized members for the target project, the condition evaluates incorrectly, leading the application to proceed with the cloning operation rather than terminating it due to insufficient privileges. This bypasses the intended isolation mechanisms designed to keep private project data confidential and restricted to designated stakeholders only.
The operational impact of this vulnerability is significant regarding data confidentiality and integrity within collaborative environments using Dolibarr. Private projects are typically used for sensitive business operations, client-specific details, or internal strategic planning where access must be strictly controlled. The ability to clone tasks into these unauthorized private spaces means that an attacker can inject structured work items containing potentially sensitive information from other parts of the system into restricted areas. This not only violates data segregation policies but also creates a pathway for further exploitation. For instance, cloned tasks might contain links or references that could be leveraged in subsequent attacks such as cross-site scripting if task descriptions are rendered without proper sanitization, although the primary risk here is unauthorized access and potential information leakage through the misplacement of sensitive workflow artifacts.
This vulnerability aligns with CWE-284 Improper Access Control, specifically reflecting issues where authorization checks fail to correctly enforce restrictions based on user roles or group memberships. It also maps closely to MITRE ATT&CK technique T1078 Valid Accounts, as it relies on legitimate authentication credentials but abuses the application's internal logic to gain unauthorized access to resources. Furthermore, because it involves manipulating input parameters during a mass action handler, it touches upon aspects of CWE-915 Improper Control of Dynamically-Identified Variables, where the dynamic nature of the target project ID is not sufficiently validated against the user's actual permissions before execution.
Mitigation strategies must focus on correcting the logical error in the source code and reinforcing access control checks. The immediate fix involves reviewing the !in_array() logic within htdocs/core/actions_massactions.inc.php to ensure that it correctly denies access when a user is not explicitly authorized for the target private project. Developers should implement explicit allow-listing or deny-listing mechanisms that strictly verify membership status before allowing any write operations like cloning tasks into private spaces. Additionally, implementing principle of least privilege checks at multiple layers can help; even if one check fails, secondary validations should prevent unauthorized data manipulation. Upgrading to version 24.0.0 or later is the primary remediation step as it addresses this specific logic flaw. Until an upgrade is performed, administrators should restrict project creation permissions to only those users who absolutely require them and monitor logs for unusual mass action patterns targeting private projects.