CVE-2026-71504 in Dolibarr
Summary
by MITRE • 08/24/2026
Dolibarr before 24.0.0 contains an improper authorization vulnerability in the Members REST API that allows attackers with only member-creation rights to reset the password of any user account, including the system administrator, without verifying password-change permissions. Attackers can supply an arbitrary user account identifier and new password in the request body to overwrite credentials and immediately lock out the legitimate account holder.
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 08/24/2026
The vulnerability identified in Dolibarr versions prior to 24.0.0 represents a critical failure in access control mechanisms within its REST API implementation, specifically affecting the user management endpoints. This flaw is classified under CWE-862, which denotes Missing Authorization, and aligns with MITRE ATT&CK technique T1078, Valid Accounts, as it allows an attacker to leverage existing low-level credentials to escalate privileges or disrupt service availability. The core issue lies in the server-side logic that processes password reset requests via HTTP POST methods directed at member-related API endpoints. While the application correctly restricts certain administrative actions based on user roles, it fails to validate whether the authenticated user initiating the request possesses the specific permission required to modify the credentials of the target account identifier provided in the payload.
From a technical perspective, the REST endpoint responsible for updating member details does not enforce strict ownership verification or role-based access control checks against the resource being modified. An attacker who has been granted basic permissions to create new members can exploit this gap by crafting a malicious API request that targets an arbitrary user ID rather than their own profile. By supplying a valid JSON body containing the target account identifier and a newly desired password, the server processes the update without verifying if the requester is authorized to perform such an action on that specific entity. This lack of object-level authorization control effectively bypasses the intended security boundaries, allowing any authenticated user with minimal privileges to overwrite credentials for high-privilege accounts, including system administrators.
The operational impact of this vulnerability is severe and multifaceted. Primarily, it enables unauthorized account takeover, granting attackers full administrative access if they target an administrator account. This can lead to complete compromise of the Dolibarr instance, allowing data exfiltration, modification of business records, or installation of persistent backdoors. Furthermore, even when targeting non-administrative accounts, the vulnerability facilitates denial-of-service attacks by locking out legitimate users through credential changes. Since password resets typically invalidate existing sessions and require re-authentication with new credentials, malicious actors can effectively disrupt business operations by rendering critical user accounts inaccessible to their rightful owners.
Mitigation strategies must address both immediate remediation and long-term architectural improvements. The most effective solution is to upgrade the Dolibarr installation to version 24.0.0 or later, where this authorization check has been corrected to ensure that users can only modify their own account details unless they hold explicit administrative privileges for user management. For environments unable to patch immediately due to compatibility constraints, implementing a Web Application Firewall rule set to monitor and restrict API calls that attempt to update member profiles with arbitrary identifiers may provide temporary relief. Additionally, organizations should enforce strict role-based access control policies, ensuring that the permission to create members is decoupled from any ability to modify existing user attributes unless explicitly required for specific administrative roles. Regular auditing of API endpoint permissions and implementing principle of least privilege across all service accounts are essential steps to prevent similar authorization bypasses in future deployments.