CVE-2026-71510: Dolibarr SQL Injection Vulnerability

CVE-2026-71510 Overview

CVE-2026-71510 is a SQL injection vulnerability in Dolibarr ERP/CRM versions before 24.0.0. The flaw resides in the users REST API, which splices unsanitized filter parameters directly into SQL WHERE clauses without column restrictions. Authenticated attackers holding user-read rights can perform blind column extraction against fields that are normally omitted from API responses, including salary figures and password verifiers. Raw database error messages returned by the same endpoint further enable column name enumeration. The weakness maps to CWE-863: Incorrect Authorization.

Critical Impact
Authenticated attackers with minimal privileges can extract password hashes and salary data by iterating blind SQL predicates through the users API filter parameter.

Affected Products

Dolibarr ERP/CRM versions prior to 24.0.0
Dolibarr users REST API endpoint (api_users.class.php)
Deployments exposing the forgeSQLFromUniversalSearchCriteria helper in functions.lib.php

Discovery Timeline

2026-08-24 - CVE-2026-71510 published to NVD
2026-08-24 - Last updated in NVD database

Technical Details for CVE-2026-71510

Vulnerability Analysis

Dolibarr exposes a universal search filter mechanism through the forgeSQLFromUniversalSearchCriteria function. The users REST API forwards attacker-supplied sqlfilters values into this helper without restricting which columns can be referenced. Because the resulting SQL is executed with the same privileges as the API user, an authenticated caller with user-read rights can reference columns their normal role would never surface. This includes hashed password verifiers, salary fields, and other sensitive user metadata omitted from JSON responses.

Extraction proceeds as a blind attack. Numeric fields such as salary are recovered through binary search predicates on the filter, while string fields including password hashes are recovered through LIKE prefix iteration. The same endpoint returns raw database error messages when a filter references an invalid column, which allows attackers to enumerate the underlying schema before running the extraction loop.

Root Cause

The root cause is missing authorization on which columns may appear in sqlfilters. forgeSQLFromUniversalSearchCriteria originally accepted any column reference the caller provided. The fix introduces a $forbiddenfields parameter so callers can enforce a deny list, and the users API supplies sensitive columns to that list.

Attack Vector

An attacker authenticates to the REST API with any account holding user-read. They send GET requests to the users endpoint with a crafted sqlfilters value that references restricted columns such as pass_crypted or salary. Response codes and error strings act as an oracle for each guess, enabling iterative recovery of secret values.

php

 * @param	int<0,1>	$noand		1=Do not add the AND before the condition string.
 * @param	int<0,1>	$nopar		1=Do not add the parenthesis around the final condition string.
 * @param	int<0,1>	$noerror	1=If search criteria is not valid, does not return an error string but invalidate the SQL
+ * @param 	string[]	$forbiddenfields		List of fields that we can't use in the filter
 * @return	string					Return forged SQL string
 * @see dolSqlDateFilter()
 * @see natural_search()
 */
-function forgeSQLFromUniversalSearchCriteria($filter, &$errorstr = '', $noand = 0, $nopar = 0, $noerror = 0)
+function forgeSQLFromUniversalSearchCriteria($filter, &$errorstr = '', $noand = 0, $nopar = 0, $noerror = 0, $forbiddenfields = array())
{
	global $db, $user;

Source: Dolibarr commit 12687f8. The patch adds a $forbiddenfields allowlist parameter that the users API populates with sensitive columns.

Detection Methods for CVE-2026-71510

Indicators of Compromise

Repeated authenticated GET requests to /api/index.php/users containing sqlfilters parameters that reference columns like pass_crypted, pass_temp, salary, or api_key.
Long sequences of requests from a single API token differing only in a numeric range or single character, indicating binary search or LIKE prefix iteration.
HTTP 500 responses or JSON error bodies containing raw database column-not-found strings from the users endpoint.
Unusually high request volume from low-privilege accounts holding only user-read.

Detection Strategies

Parse web server access logs for sqlfilters values that include operators such as :like:, :<:, :>: targeting user table columns.
Alert when a single API session issues hundreds of user-list requests within a short window.
Correlate 4xx and 5xx spikes on the users REST endpoint with authenticated session identifiers.

Monitoring Recommendations

Ingest Dolibarr web and application logs into a centralized log platform and retain filter parameters for query-level review.
Track per-user-token request rates against the REST API and baseline normal behavior for user-read accounts.
Monitor database error rates from the Dolibarr backend to detect column enumeration attempts.

How to Mitigate CVE-2026-71510

Immediate Actions Required

Upgrade Dolibarr to version 24.0.0 or later, which introduces the $forbiddenfields restriction in forgeSQLFromUniversalSearchCriteria.
Rotate password hashes and API keys for any account that may have been exposed while a vulnerable version was reachable.
Audit which accounts hold user-read permission and revoke it from tokens that do not require it.

Patch Information

The fix landed in Dolibarr commit 12687f8 and ships in Dolibarr 24.0.0. Additional technical context is available in the Codeant SQL injection research and the VulnCheck advisory.

Workarounds

Restrict network access to the Dolibarr REST API through firewall rules or reverse-proxy allowlists until patching is complete.
Disable the REST API module entirely if it is not required for integrations.
Reduce or suppress verbose database error messages returned by the application to blunt column enumeration.

bash

# Example nginx restriction limiting Dolibarr REST API access to trusted networks
location /api/ {
    allow 10.0.0.0/8;
    deny  all;
    proxy_pass http://dolibarr_backend;
}