CVE-2026-71511 in Dolibarr
Summary
by MITRE • 08/24/2026
Dolibarr before 24.0.0 contains a sensitive data exposure vulnerability in the Members REST API that allows authenticated attackers with member-read rights to retrieve bcrypt password verifiers by querying member endpoints. Attackers can call the individual member or member list endpoints to obtain crypted password verifier fields that are not filtered by the base API serializer or the Members API class, potentially enabling offline password cracking attacks.
Be aware that VulDB is the high quality 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 data serialization and access control within its RESTful application programming interface. Specifically, this flaw resides in the Member management module, where the API endpoints responsible for retrieving member information fail to properly filter sensitive fields before returning them to the client. While Dolibarr is designed as an open-source ERP and CRM system widely used by small to medium-sized enterprises, the exposure of cryptographic password hashes undermines the fundamental security assumption that stored credentials are protected from unauthorized access even when user accounts themselves are compromised or exposed through other means.
The technical root cause lies in the serialization logic employed by the Members REST API class and its associated base serializer. When an authenticated attacker with member-read permissions queries either the individual member endpoint or the bulk member list endpoint, the system constructs a JSON response containing various attributes of the requested members. The implementation fails to explicitly exclude sensitive fields such as password verifiers from this output structure. Consequently, these hashed values are transmitted in plaintext within the API response payload, effectively bypassing any intended obfuscation or masking mechanisms that should have been applied at the data presentation layer. This is a classic example of improper object serialization where security-sensitive properties are inadvertently exposed due to incomplete filtering rules.
From an operational perspective, this vulnerability allows for significant offline password cracking attacks against user accounts within the Dolibarr instance. Although bcrypt hashes are computationally expensive and resistant to rapid brute-forcing compared to older hashing algorithms like MD5 or SHA-1, they are not impervious to attack if sufficient time and computational resources are available. An attacker who obtains these verifiers can utilize specialized tools such as Hashcat or John the Ripper to attempt recovery of the original plaintext passwords. The success rate of this attack depends heavily on password complexity; however, many users employ weak or reused passwords across multiple services. If successful, the recovered credentials provide the attacker with valid authentication tokens for the Dolibarr application and potentially other systems where those same credentials are used, leading to a broader compromise of organizational data and infrastructure.
This vulnerability aligns closely with CWE-209, which describes the generation of an error message that includes sensitive information, although in this case it is more accurately categorized under CWE-538: Insertion of Sensitive Information into an Object or File, specifically regarding API responses. Furthermore, from a tactical standpoint within the MITRE ATT&CK framework, this flaw facilitates Credential Access techniques such as T1078: Valid Accounts and potentially T1110: Brute Force if combined with automated cracking tools. The attacker leverages existing valid credentials to access sensitive data, which is then used to expand their foothold through credential reuse or offline decryption.
To mitigate this risk, organizations running Dolibarr versions earlier than 24.0.0 must upgrade immediately to version 24.0.0 or later, where the serialization logic has been corrected to exclude password verifiers from API responses for all user roles except those with explicit administrative privileges required for system maintenance. For environments that cannot be upgraded instantly due to compatibility constraints, a temporary workaround involves restricting access to the Members REST API endpoints via network-level controls such as firewalls or reverse proxy rules, ensuring that only trusted internal services can query these paths. Additionally, implementing strict rate limiting on authentication-related endpoints and enforcing multi-factor authentication for all user accounts can significantly reduce the impact of potential credential compromise by adding layers of defense beyond static password hashes. Regular security audits of API response structures should also be conducted to ensure no other sensitive fields are inadvertently exposed through similar serialization oversights in future updates or custom modules.