Description

Dolibarr is an open-source enterprise resource planning and customer relationship management application. Prior to 22.0.5 and 23.0.1, there is a SQL injection vulnerability in the Third Party company update functionality. The application concatenates the  localtax1_value  and  localtax2_value  properties into an SQL UPDATE statement without numeric conversion or other appropriate sanitization. An authenticated user with Third Party create or edit permission can submit crafted  lt1  or  lt2  POST parameters to read sensitive database information, including password hashes, API keys, and business data, or modify third-party records. This issue is fixed in versions 22.0.5 and 23.0.2.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "8.8",
  "pubDate": "2026-11-05T22:18:41.777Z",
  "pubdate": "2026-11-05T22:18:41.777Z",
  "executiveSummary": "Dolibarr is susceptible to a SQL injection vulnerability within its Third Party company update functionality, identified in versions prior to 22.0.5 and 23.0.1. The flaw resides in the improper handling of user-supplied input for specific tax-related parameters during database update operations. An authenticated attacker possessing Third Party create or edit permissions can exploit this vulnerability to perform unauthorized database queries, potentially leading to the exfiltration of sensitive information such as password hashes, API keys, and confidential business data. Furthermore, the vulnerability permits the modification of third-party records, posing a severe risk to data integrity and system confidentiality. Exploitation requires valid authentication and specific user permissions, restricting the attack surface to authorized users, though the potential for lateral movement or administrative compromise remains significant. The vulnerability is effectively resolved in versions 22.0.5 and 23.0.2.",
  "technicalDetails": "The root cause of this vulnerability is improper neutralization of special elements used in an SQL command, specifically within the Third Party company update logic. The application fails to perform numeric conversion or enforce rigorous sanitization on the 'localtax1_value' and 'localtax2_value' properties before integrating them into an SQL UPDATE statement. By failing to utilize parameterized queries or prepared statements, the application creates a direct vector for SQL injection via the 'lt1' and 'lt2' POST parameters.\nThe exploitation flow begins with an attacker who must have established, authenticated access to the Dolibarr instance with 'Third Party' create or edit permissions. Upon initiating an update to a Third Party record, the attacker can manipulate the 'lt1' or 'lt2' POST parameters by injecting malicious SQL syntax. Because these inputs are concatenated directly into the backend query, the database engine executes the injected code as part of the intended UPDATE statement.\nThe attacker can leverage this primitive to perform Union-based SQL injection, allowing them to append results from unauthorized queries to the application's legitimate response. This enables the systematic extraction of data from the database, including sensitive credentials, API keys, and proprietary organizational data. Beyond simple data exfiltration, the capability to inject arbitrary SQL allows an attacker to alter the logic of the UPDATE statement, potentially leading to unauthorized modification of database records or escalation of privileges by manipulating administrator accounts or system configurations.\nThis vulnerability affects versions of Dolibarr prior to 22.0.5 and 23.0.1. The attack surface is restricted to the web interface where the Third Party update functionality is exposed. The absence of input validation at the application layer means the database is effectively defenseless against malicious payloads transmitted through these specific parameters. The lack of strict typing for tax value fields facilitates this breach, as the application assumes that provided values will conform to expected numeric formats without verifying them programmatically. The impact is significant, as it provides a pathway for total compromise of the database tier if the application's service account possesses broad database permissions."
}