Dolibarr User REST API Authorization Flaw Exposes Payroll Data

Dolibarr before 24.0.0 contains a SQL injection vulnerability in the users REST API that allows authenticated attackers with user-read rights to extract sensitive data by splicing unsanitized filter parameters into SQL WHERE clauses without column restrictions. Attackers can perform binary search on numeric fields and LIKE prefix iteration on string fields to recover salary figures and password verifiers omitted from normal API responses, while raw database error messages in the same endpoint enable column name enumeration.

• Dolibarr dolibarr: every semver version less than 24.0.0 is recorded as affected.
• The record does not identify a separately verified parallel branch or distribution outside that range as unaffected.
• 24.0.0 is associated by the technical sources and patch reference with the fix; the status of other release branches should not be inferred solely from the existence of that fix.

The Dolibarr users REST API checks the user-read permission before allowing a caller to list users, but does not apply the same authorization decision when processing fields named by filter parameters. The Users::index() route passes filters to forgeSQLFromUniversalSearchCriteria(), while dolForgeSQLCriteriaCallback() sanitizes column-name syntax without checking whether the caller is authorized to reference the selected column. As a result, an account allowed to list users can use a returned row or empty result as a boolean oracle for numeric fields, and prefix matching to recover parts of string fields that are removed from normal responses. The analysis identifies fields including salary, salaryextra, thm, tjm, and transformed password-verifier values; raw database errors can also disclose column names. The CNA description labels the issue SQL injection, but the technical analysis indicates that the filter removes characters needed for arbitrary SQL injection; the confirmed core failure is missing column-level authorization rather than the ability to break SQL syntax.

The issue is reachable over the network through authenticated REST requests, requires no user interaction, and does not require administrative access. An attacker needs at least permission to list users, represented by user->user->lire. Public technical research demonstrates the technique in an isolated Dolibarr environment using authenticated GET requests; the available evidence does not establish exploitation against deployed third-party systems. The record marks a public exploit, but does not identify a campaign, victim, or confirmed abuse outside testing.

The flaw expands read access indirectly: an account allowed to list users can test conditions on columns that the account is not authorized to view. This can disclose salary data, cost rates, and some transformed password-verifier values through repeated filter queries. The primary supported impact is loss of confidentiality within the database data reachable by the endpoint; the record does not establish data modification or service disruption. Public analysis also does not establish that the disclosed verifier can be used directly for login or that an account was taken over. Returning raw database errors increases the reconnaissance value by exposing schema information.

• Salary and personnel cost data can be disclosed to accounts that only need permission to list users, increasing privacy, competitive, and compliance risk.
• Reconstructing multiple records can expose workforce cost structures rather than only one isolated field.
• Password-verifier or transformed password data may be collected even though it is absent from normal responses. Public analysis states that the recovered value is not directly usable as a login credential, but exposure of authentication-related data still warrants investigation.
• Raw database errors can reveal column names and help map the application's schema.
• The available evidence does not confirm data modification, service disruption, account takeover, or a specific intrusion.

1. Upgrade Dolibarr to 24.0.0, which is the release documented as containing the fix for this issue.
2. Before upgrading, temporarily remove user->user->lire from accounts, tokens, and integration identities that do not need to list users. This is a temporary mitigation, not a replacement for the fix.
3. Restrict access to the User REST API from networks, integrations, or identities that do not require it while the upgrade is being completed.
4. After updating, verify that the endpoint applies a column allowlist and enforces authorization for payroll fields and credential fields excluded from responses. Do not rely only on SQL-character sanitization.
5. Review access and application logs for the period in which an affected version was exposed. If unusual filters or verifier collection are found, follow the organization's incident-response and credential-assessment procedures; the available evidence does not require a conclusion that account takeover occurred.

• Inventory Dolibarr servers and identify versions before the fixed release, prioritizing deployments with the User REST API enabled.
• Enumerate accounts, tokens, and integration accounts holding user->user->lire, especially identities that do not need personnel-data access but can still call the users API.
• Review User REST API access logs for authenticated requests that filter on sensitive fields such as salary, salaryextra, thm, tjm, or credential fields omitted from ordinary responses.
• Check application and database logs for raw SQL errors or unknown-column errors from the same endpoint. Treat these as investigation leads, not as a confirmed standalone IOC.
• Compare the API's normal removal of payroll and verifier fields with unusual filter results. The absence of log evidence or the absence of a field from a normal response does not prove that the deployment is safe.