CVE-2026-81728 in Dolibarr
Summary
by MITRE • 08/27/2026
Dolibarr before 24.0.0 contains a SQL injection in its CSV and XLSX import wizard. The wizard reads its update keys with GETPOST('updatekeys', 'array') in htdocs/imports/import.php, which applies only the generic alphanohtml filter: that strips HTML but leaves SQL keywords, comment markers, parentheses, spaces and quotes intact. import_insert() in htdocs/core/modules/import/import_csv.modules.php then iterates the submitted values and builds a filter with $where[] = $key.' = '.$data[$key], having first applied preg_replace('/^.*\./i', '', $key), an alias strip that does nothing to a value containing no dot. The assembled string is executed through $this->db->query(). The injected SELECT resolves the row id that the import then assigns to $lastinsertid, which becomes the WHERE target of a subsequent UPDATE, so a UNION SELECT returning an attacker-chosen integer both exfiltrates arbitrary table content and redirects which row the import overwrites; for category link tables the raw filter array is spliced into that UPDATE directly. The interface offers a fixed list of legitimate column codes but the server never checks the submitted values against it. A user holding the import permission can exploit this. Release 23.0.4 does not carry the fix; the allow-list test was added in 24.0.0.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 08/27/2026
Dolibarr versions prior to 24.0.0 contain a critical SQL injection vulnerability within its CSV and XLSX import wizard functionality, specifically located in the htdocs/imports/import.php script. The root cause of this flaw lies in the insufficient sanitization of user-supplied input used as database query filters. When users initiate an import operation, the application retrieves update keys using the GETPOST function with an array type specification. This data is then subjected to a generic alphanohtml filter which strips HTML tags but fails to neutralize SQL-specific characters such as quotes, parentheses, spaces, and comment markers. Consequently, maliciously crafted input containing SQL syntax remains intact within the variable stream that feeds into the database query construction logic.
The vulnerability manifests in the import_insert function located in htdocs/core/modules/import/import_csv.modules.php. This function iterates over the submitted key-value pairs to construct a WHERE clause for an INSERT statement by concatenating keys and values directly without proper parameterization or rigorous validation. Although there is a preliminary attempt to sanitize keys using a regular expression that removes prefixes ending with a dot, this logic fails when input does not contain such characters. The resulting string is passed directly to the database query execution method, allowing attackers to inject arbitrary SQL commands into the filter condition. This represents a classic case of improper neutralization of special elements used in an SQL command, categorized under CWE-89.
The operational impact of this vulnerability extends beyond simple data exfiltration due to the specific behavior of the import mechanism. When an attacker crafts a UNION SELECT payload within the input fields, the database resolves the row ID from the injected query and assigns it to a variable that subsequently controls a following UPDATE statement. This means that by manipulating the WHERE clause target through the injection point, an authenticated user can redirect which record is overwritten during the import process. For category link tables, where raw filter arrays are spliced directly into update queries, this allows for precise control over database modifications, potentially leading to data integrity issues or unauthorized privilege escalation depending on table structures and permissions.
Exploitation requires a valid account with import permissions, aligning with ATT&CK technique T1059 Command and Scripting Interpreter where SQL commands are executed via the application interface. The attacker can exfiltrate arbitrary content from any accessible database tables by leveraging UNION-based injection techniques to return selected data within the result set of the initial query. Furthermore, because the server does not validate submitted column codes against a fixed list of legitimate options, there is no defense-in-depth mechanism to prevent invalid or malicious keys from reaching the SQL engine. This lack of allow-list validation significantly lowers the barrier for exploitation compared to scenarios where input types are strictly enforced at multiple layers.
Mitigation strategies must focus on both immediate patching and long-term architectural improvements. The primary remediation is upgrading Dolibarr to version 24.0.0 or later, which introduces an essential allow-list test that validates submitted values against a predefined set of legitimate column codes before they are processed by the import logic. For organizations unable to upgrade immediately, implementing Web Application Firewall rules can help detect and block SQL injection patterns in POST requests targeting the import endpoints. Additionally developers should refactor the affected code paths to utilize prepared statements with parameterized queries instead of string concatenation for building SQL filters. This ensures that user input is treated strictly as data rather than executable code, effectively neutralizing injection attempts regardless of the content submitted by the client side.