Insufficient credential redaction in Dolibarr Members REST API exposes bcrypt verifiers

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.

• Dolibarr dolibarr: versions from 0 and less than 24.0.0 are marked affected.

• Component: Members REST API, particularly responses from individual-member and member-list endpoints.

• Fix: Dolibarr 24.0.0 is identified as the fixed release. The patch adds removal of pass_indatabase_crypted from API results and extends redaction for the password field family. The supplied affected data does not separately describe parallel branches or custom builds.

Dolibarr's Members REST API performs the expected permission check before returning data, but its response cleaning does not remove all credential fields. An authenticated caller with member-read permission, represented by adherent.lire, can query an individual member or member-list endpoint and receive a bcrypt password verifier.

The vulnerable flow is the Members API _cleanObjectDatas() implementation in htdocs/adherents/class/api_members.class.php, which relies on the shared cleaner in htdocs/api/class/api.class.php. The shared cleaner removes pass and pass_indatabase but leaves pass_indatabase_crypted, pass_crypted, and pass_temp; pass_indatabase_crypted is the live verifier used for login checks. The Members API does not add a second redaction step before serializing the response.

Both individual-member and member-list routes use the same cleaning logic, so one legitimate read permission can expose verifiers for multiple members. This is insufficient credential protection after an authorized read, not a missing authentication check for anonymous callers. The available evidence does not establish how custom extensions or alternate serializers behave outside the documented request paths.

The vulnerability is reachable over the network by an authenticated account with member-read rights; administrator privileges and additional user interaction are not required. The normalized record marks a public exploit, and public research provides a reproducible demonstration that retrieves the verifier from both an individual-member query and a member-list query.

The supplied exploitability attributes indicate low complexity because the attacker only needs to use a legitimately issued read permission. The published demonstration ran against a self-contained local Docker deployment, which proves the data-exposure path but does not by itself establish abuse against production environments.

A bcrypt verifier is not a plaintext password and does not provide immediate direct login. The attacker must perform offline cracking, with success depending on password strength and reuse.

The flaw compromises the confidentiality of password verifiers in member records that an authorized caller can read. A bcrypt verifier is not plaintext and does not immediately grant login access, but it enables offline password guessing without the online rate limits, lockouts, or failed-attempt counters that protect the live authentication service.

Consequences may include compromise of member accounts when passwords are weak, as well as exposure of other services when passwords are reused. Back-office staff accounts may also be at risk if the deployment copied the same verifier from a member into a staff account, but the available material confirms this only as a source-level possibility, not as a demonstrated exploitation path. The issue is documented as credential disclosure; the record does not establish direct data modification or service disruption from this flaw alone.

• Credential confidentiality: A key issued to look up members can retrieve member password verifiers even though the business function does not require access to the password store.

• Identity and access risk: The verifiers can be cracked offline. If members reuse passwords elsewhere, the exposed verifier together with login or email data may increase the risk of unauthorized access outside Dolibarr.

• Difficult incident scoping: A valid member read can look like ordinary operational access. Public research states that this read path may not create a dedicated event, so existing logs may not be sufficient to determine which verifiers were retrieved.

• Potential staff-account exposure: Source review identified a possible relationship where Dolibarr provisions a back-office user from a member and copies the verifier, but that escalation path was described as source-level behavior and was not executed as a demonstrated exploit.

1. Upgrade each affected deployment to Dolibarr 24.0.0, the fixed release identified by the CNA data, release information, and patch.
2. Treat any verifier returned by an affected deployment as exposed. Require password changes for members who may be in scope and review whether those passwords were reused in other services.
3. Review API keys and users with member-read permission, and revoke that permission from keys that do not strictly need it, especially reporting, synchronization, or legacy integration keys.
4. After upgrading, test both individual-member and member-list queries with a least-privileged account. Confirm that pass_indatabase_crypted, pass_crypted, pass_temp, and equivalent password fields are absent from responses.
5. The record does not provide a complete workaround that replaces upgrading. Reducing member-read access is a temporary risk-reduction measure, not a substitute for the fix.

1. Inventory every Dolibarr deployment and identify the running version, then compare it with the affected boundary in affected_summary.
2. Enumerate API keys, users, and groups with member-read permission, especially adherent.lire. Prioritize keys issued to dashboards, CRM synchronization jobs, or operational accounts that should not access credential material.
3. If an API gateway or other control retains response bodies, search for pass_indatabase_crypted, pass_crypted, or pass_temp in responses from individual-member and member-list endpoints. Do not copy exposed verifiers into new tickets or logs.
4. Review proxy and API logs for member reads performed by low-privilege keys. These requests may resemble routine member access, so detection should not depend on a special security event.
5. After patching, use a test account with only member-read permission to check representative responses and confirm that the password field family is absent.
6. If a verifier was found in a response, treat it as credential exposure. The absence of unusual log evidence does not prove that the data was not retrieved.