CVE-2026-77923: Dolibarr Authorization Bypass Vulnerability

CVE-2026-77923 Overview

CVE-2026-77923 is an authorization bypass vulnerability in Dolibarr ERP/CRM versions 21.0.0 through releases prior to 24.0.0. The flaw resides in the clonetasks mass action handler within htdocs/core/actions_massactions.inc.php. An inverted boolean condition in the private-project membership check allows authenticated users with project creation permission to clone tasks into private projects they should not access. The vulnerability is classified under CWE-863: Incorrect Authorization.

Critical Impact
Authenticated low-privilege users can bypass private-project access controls and inject cloned tasks into unauthorized projects, breaking tenant isolation for project data.

Affected Products

Dolibarr ERP/CRM 21.0.0 and later
Dolibarr ERP/CRM versions before 24.0.0
The clonetasks mass action handler in htdocs/core/actions_massactions.inc.php

Discovery Timeline

2026-08-24 - CVE-2026-77923 published to the National Vulnerability Database (NVD)
2026-08-24 - Last updated in NVD database

Technical Details for CVE-2026-77923

Vulnerability Analysis

The vulnerability affects the mass-action task cloning workflow in Dolibarr. When a user clones tasks into a target project, the application must verify that the user is an authorized contact of that project before allowing the operation on private projects. The check is implemented by comparing the target project ID against a list of projects the user is authorized to access, returned by getProjectsAuthorizedForUser().

A logic error in the conditional statement inverts the intended access decision. Instead of granting the iscontactofnewproject flag when the target project is present in the authorized list, the vulnerable code grants it when the project is absent. This inversion means users without membership pass the check, while legitimate members are rejected. Exploitation requires only an authenticated account with project creation permission and no additional user interaction.

Root Cause

The root cause is a negated in_array() condition guarding the private-project membership evaluation. The check was written as !in_array($newproject->id, $tmparray) when the correct semantic requires membership, not absence. Dolibarr's authorization model relies on this flag to gate task insertion into private projects, so the boolean inversion silently converts the control from allow-list to deny-list behavior.

Attack Vector

An attacker authenticates to Dolibarr with an account granting project creation rights. The attacker selects one or more source tasks and invokes the clonetasks mass action, specifying a target private project the attacker does not belong to. The flawed authorization branch sets iscontactofnewproject = 1, and the cloned tasks are written into the unauthorized project. The impact is limited to integrity of project data because the cloning path does not directly expose confidential fields to the attacker.

php

 	if (empty($newproject->public)) {
 		$tmps = $newproject->getProjectsAuthorizedForUser($user, 0, 1, 0, '(fk_statut:=:1)');	// We check only open project (cloning on closed is not allowed)
 		$tmparray = explode(',', $tmps);
-		if (!in_array($newproject->id, $tmparray)) {
+		if (in_array($newproject->id, $tmparray)) {
 			$iscontactofnewproject = 1;
 		}
 	}

Source: Dolibarr GitHub commit 1730aa5. The patch removes the negation from the in_array() check so the membership flag is set only when the target project appears in the authorized list.

Detection Methods for CVE-2026-77923

Indicators of Compromise

Task records appearing in private projects with fk_user_creat values that do not match any authorized project contact
Application access logs showing HTTP POST requests to endpoints handling the massaction=clonetasks parameter followed by task creation in projects the requesting user is not a member of
Sudden increase in llx_projet_task inserts referencing target fk_projet values owned by other tenants or departments

Detection Strategies

Review web server and PHP audit logs for requests carrying massaction=clonetasks along with a projectid parameter and correlate the requesting user against the target project's contact list
Query the Dolibarr database to identify tasks whose creating user is not listed in llx_element_contact for the parent private project
Compare application version strings against the fixed release 24.0.0 across all Dolibarr instances to identify vulnerable deployments

Monitoring Recommendations

Enable Dolibarr's built-in security event log and forward records to a centralized log platform for correlation
Alert on mass-action operations executed by non-administrative accounts against private projects
Track anomalous project membership changes and task creation spikes tied to individual user sessions

How to Mitigate CVE-2026-77923

Immediate Actions Required

Upgrade Dolibarr to version 24.0.0 or later, which contains the corrected in_array() check
Audit llx_projet_task records for unauthorized entries created between the deployment of a 21.x–23.x release and the patch date
Restrict the project creation permission (Projet->creer) to trusted users until the upgrade is applied

Patch Information

The fix is delivered in Dolibarr release 24.0.0. The single-line correction inverts the flawed boolean, restoring the intended allow-list semantics in htdocs/core/actions_massactions.inc.php. Additional advisory context is available in the VulnCheck advisory for the clonetasks authorization bypass.

Workarounds

Temporarily revoke the project creation permission from non-administrative roles through Dolibarr's user and group management interface
Disable mass actions for the project and task modules by removing the clonetasks option from custom deployments until the upgrade is scheduled
Apply the upstream one-line source change to htdocs/core/actions_massactions.inc.php as an interim hotfix if a full upgrade is not immediately possible

bash

# Verify installed Dolibarr version and confirm the patched release
grep -R "DOL_VERSION" htdocs/filefunc.inc.php
# Expected output for a patched installation:
# $conf->global->MAIN_VERSION_LAST_INSTALL = '24.0.0';