Description

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.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "8.1",
  "pubDate": "2026-08-27T20:18:55.183Z",
  "pubdate": "2026-08-27T20:18:55.183Z",
  "executiveSummary": "Dolibarr versions prior to 24.0.0 are susceptible to a critical SQL injection vulnerability within the CSV and XLSX import wizard.\nThe vulnerability stems from inadequate sanitization and a lack of input validation on the 'updatekeys' parameter processed by htdocs/imports/import.php.\nAn authenticated attacker with import permissions can manipulate database queries to exfiltrate sensitive information or perform unauthorized data modification.\nBy injecting malicious SQL statements via the import process, an attacker can control the 'lastinsertid', effectively hijacking subsequent UPDATE operations.\nThis vulnerability poses a significant risk to data integrity and confidentiality, as it allows for arbitrary table content access and row-level data corruption.\nSuccessful exploitation requires the attacker to hold legitimate 'import' permissions within the application, limiting the attack surface to authenticated users, though the potential impact is severe due to the direct interaction with the underlying database backend.\nThe vulnerability remains unpatched in version 23.0.4; users must upgrade to version 24.0.0 or later to implement the necessary allow-list validation.",
  "technicalDetails": "The vulnerability resides in the htdocs/imports/import.php file, where the application retrieves 'updatekeys' via the GETPOST('updatekeys', 'array') function. This function utilizes the 'alphanohtml' filter, which is insufficient for preventing SQL injection as it only strips HTML tags while permitting critical SQL control characters such as single quotes, parentheses, spaces, and comment markers.\nWithin the import_insert() function located in htdocs/core/modules/import/import_csv.modules.php, the application iterates over submitted values to construct a WHERE clause. Although the code attempts to sanitize the key using preg_replace('/^.*\\./i', '', $key), this mechanism is ineffective against inputs lacking a dot character, allowing malicious SQL fragments to pass through.\nThe constructed SQL query string is passed directly to the $this->db->query() method. An attacker can craft a payload containing a UNION SELECT statement. This allows the attacker to inject arbitrary subqueries into the WHERE clause, which resolves the row ID used for the subsequent update operation.\nThe attack flow proceeds as follows: First, the attacker provides a malicious payload in the 'updatekeys' parameter during the import process. Second, the backend logic executes the tainted query, which returns an attacker-supplied integer instead of the intended row identifier. Third, the application assigns this injected value to $lastinsertid. Fourth, this manipulated ID is used as the target for a subsequent UPDATE command. In the specific case of category link tables, the raw filter array is concatenated directly into the UPDATE statement, granting the attacker further control over the data modification process.\nBecause the server fails to cross-reference submitted column codes against a fixed allow-list of legitimate identifiers, the application blindly trusts user input throughout the import pipeline.\nThis flaw enables two primary attack vectors: sensitive data exfiltration through UNION-based SQL injection and unauthorized data modification by hijacking the UPDATE target ID. The impact is elevated by the ability to influence core database operations, potentially compromising the integrity of the entire application state."
}