CVE-2026-81729 in Dolibarr
Summary
by MITRE • 08/27/2026
Dolibarr before 23.0.4 authorizes REST API document deletion against the wrong permission. Documents::delete() in htdocs/api/class/api_documents.class.php calls dol_check_secure_access_document() with the mode argument 'read' when handling DELETE /api/index.php/documents, while the sibling builddoc() path passes 'write', the correct mode for an operation that modifies stored data. An authenticated API user who holds only a read permission for a document-bearing module, for example societe:lire or facture:lire, and no create, write, delete or admin permission, therefore passes the check and can permanently delete that module's documents: third-party files, invoices, orders, proposals, project files and generated PDFs, with no recovery path. The call site is htdocs/api/class/api_documents.class.php:1276 in 23.0.3 and passes 'write' from 23.0.4 onward.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 08/27/2026
The vulnerability identified in Dolibarr versions prior to 23.0.4 represents a critical authorization bypass within the REST API layer, specifically affecting document management operations. This flaw stems from an incorrect implementation of access control checks when handling HTTP DELETE requests for documents. The core issue lies in the function call sequence within htdocs/api/class/api_documents.class.php at line 1276, where the system invokes dol_check_secure_access_document to validate user permissions before executing a deletion. However, this validation is performed using the mode argument set to 'read', which contradicts the nature of the operation being executed. In security logic, deleting data constitutes a modification or destructive action that requires write-level privileges, not read-only access. By checking for read permission instead of write permission, the application fails to enforce the principle of least privilege effectively, allowing users with insufficient rights to perform actions beyond their intended scope.
From an operational perspective, this misconfiguration allows any authenticated API user who possesses only read permissions for a specific module, such as societe:lire or facture:lire, to permanently delete associated documents without needing create, write, delete, or admin privileges. The impact is severe because it affects critical business data including third-party files, invoices, orders, proposals, project files, and generated PDFs. Once these documents are deleted via the API endpoint DELETE /api/index.php/documents, there is no recovery path available within the standard application interface, leading to potential data loss and disruption of business processes. This vulnerability effectively undermines the integrity of stored information by permitting unauthorized destruction of assets that should be protected from users with only observational access rights.
This flaw aligns closely with CWE-269, which describes Improper Privilege Management, as the system grants capabilities exceeding the user's assigned role. Furthermore, it can be mapped to MITRE ATT&CK technique T1078, Valid Accounts, specifically in the context of using legitimate credentials to perform unauthorized actions due to flawed access control logic. The discrepancy between this endpoint and other similar functions like builddoc(), which correctly passes 'write' as the mode argument, highlights an inconsistency in how security checks are applied across different API methods within the same class. This inconsistency suggests that while some parts of the application adhere to proper authorization standards, others contain logical errors that can be exploited by attackers with minimal access levels.
Mitigation for this vulnerability requires immediate patching to version 23.0.4 or later, where the code has been corrected to pass 'write' as the mode argument in the relevant function call. Until an upgrade is feasible, administrators should restrict API access to trusted IP addresses and ensure that users are granted only the minimum necessary permissions for their roles. Implementing strict input validation and ensuring consistent application of security checks across all API endpoints is essential to prevent similar authorization bypasses. Regular audits of permission logic in custom modules or extensions integrated with Dolibarr can also help identify and rectify analogous flaws before they lead to data compromise.