Dolibarr ERP EUVD-2026-65087

The attacker must be authenticated to Dolibarr with the 'project creation' permission assigned to their user role (reflected by PR:L in the CVSS vector). The target must be a private project to which the attacker has no membership - the flaw is specific to the private-project membership gate within the clonetasks handler and does not affect public projects. No non-default system configuration is required beyond a standard Dolibarr installation with the project module active. Exploitation is bounded by: (1) mandatory authentication - unauthenticated access is not possible; (2) the project-creation entitlement, which administrators may not grant to all user roles; (3) the affected version range 21.0.0 to 23.x only; and (4) impact is integrity-only - no confidentiality exfiltration or system-level compromise is achievable through this flaw alone.

The CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:L/UI:N with VI:L only) yields a score of 5.3, accurately reflecting bounded impact: exploitation requires authentication (PR:L), and the consequence is restricted to unauthorized task cloning with no confidentiality or availability breach. No EPSS score was supplied in the input data, preventing quantitative exploitation-probability comparison. There is no CISA KEV listing and no public proof-of-concept identified at time of analysis. The attack complexity is genuinely low once authenticated - no special race conditions, timing windows, or chained vulnerabilities are needed. Real-world priority is moderate for organizations using Dolibarr's private project controls to segregate sensitive initiatives; for deployments where all authenticated users share visibility across projects, practical impact is negligible. The absence of both EPSS data and KEV status, combined with the authentication prerequisite, positions this as a patch-cycle priority rather than an emergency response item.

An authenticated Dolibarr employee with standard project-creation rights enumerates or guesses the numeric ID of a private project containing sensitive business data they should not access. They craft and submit a clonetasks mass action HTTP request targeting that private project ID; the inverted !in_array() check incorrectly validates their membership and completes the clone operation, injecting tasks into the confidential project and potentially polluting its task history or exposing project existence. No public exploit code exists, but the technique requires only standard HTTP request manipulation with a valid session token.