Description

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.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "6.5",
  "pubDate": "2026-08-27T20:18:55.340Z",
  "pubdate": "2026-08-27T20:18:55.340Z",
  "executiveSummary": "Dolibarr versions prior to 23.0.4 contain an improper authorization vulnerability within the REST API document management subsystem.\nThe vulnerability arises from a misconfiguration in the permission check logic, where the system incorrectly validates deletion requests against read-only access rights rather than write-access requirements.\nThis flaw allows authenticated users, who possess only read-level permissions for specific modules such as third-party records or invoices, to permanently delete associated documents.\nThe impact is significant, as the exploitation results in the irreversible loss of critical business documentation, including orders, proposals, project files, and generated PDFs.\nThis constitutes an escalation of privileges where an attacker with minimal read access can perform destructive operations usually reserved for administrative or write-privileged roles.\nThe vulnerability is localized to the REST API interface, and exploitation requires valid authentication as a user with at least read access to the relevant module.",
  "technicalDetails": "The root cause of the vulnerability is located in htdocs/api/class/api_documents.class.php, specifically within the Documents::delete() method. The application implements an authorization check using the function dol_check_secure_access_document(). During the deletion workflow, the code incorrectly passes the argument 'read' as the required permission mode instead of 'write'.\nIn the context of the REST API, 'write' access is the mandatory authorization level required to modify or remove data stored within the system. By erroneously validating the DELETE request against the 'read' permission, the API architecture effectively grants delete authority to any user capable of satisfying the 'read' requirement.\nThe attack flow proceeds as follows: An authenticated API user with limited privileges (e.g., holding 'societe:lire' or 'facture:lire' permissions) initiates an HTTP DELETE request to the /api/index.php/documents endpoint. The backend processing logic calls Documents::delete(), which invokes the access control function. Because the function call explicitly requests a check for 'read' access, the authorization layer validates the session against these minimal permissions. The check succeeds, and the application proceeds to execute the file deletion routine on the server's filesystem.\nThe vulnerable component is identified at line 1276 of htdocs/api/class/api_documents.class.php. This implementation error creates a functional bypass that ignores the principle of least privilege, allowing users to destroy data they are only meant to view.\nThe exploitability of this flaw is restricted to authenticated users. However, since many business environments allow for standard user API access, the threat surface includes any internal or external actor with valid credentials assigned to restricted roles. Because the deletion results in permanent file removal without a designated recovery path within the application interface, the post-exploitation impact is a total loss of integrity and availability for the targeted document modules.\nVersion 23.0.4 corrects this logic by explicitly requiring the 'write' permission mode for the Documents::delete() function call, effectively patching the authorization bypass."
}