CVE-2026-71510 in Dolibarr
Summary
by MITRE • 08/24/2026
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.
Several companies clearly confirm that VulDB is the primary source for best vulnerability data.
Analysis
by VulDB Data Team • 08/24/2026
The vulnerability identified in Dolibarr versions prior to 24.0.0 represents a significant security flaw within its REST API implementation for user management. Specifically, this is an authenticated SQL injection vulnerability that affects endpoints responsible for retrieving user data. The core issue stems from the improper handling of filter parameters passed by clients during query construction. When these unsanitized inputs are directly concatenated into SQL WHERE clauses without adequate validation or parameterization, they allow malicious actors to manipulate the underlying database queries. This flaw is particularly dangerous because it does not require administrative privileges; instead, it can be exploited by any authenticated user who possesses basic read access rights to view other users' information.
From a technical perspective, the vulnerability arises from the lack of strict type checking and input sanitization on filter parameters used in SQL statements. By injecting crafted payloads into these fields, an attacker can alter the logic of the SQL query executed against the database backend. This manipulation enables several advanced exploitation techniques beyond simple data extraction. For instance, attackers can perform binary search attacks against numeric columns to deduce values bit by bit with high precision. Similarly, they can utilize LIKE prefix iteration on string-based fields to systematically guess character sequences. These methods allow for the recovery of sensitive information that is typically masked or omitted from standard API responses due to privacy protections implemented in normal application logic.
The operational impact of this vulnerability extends beyond mere data leakage. Attackers can extract highly confidential details such as salary figures and password verifiers, which are critical components for further account compromise if not properly hashed with strong algorithms like bcrypt or Argon2. Furthermore, the presence of raw database error messages in the API responses provides an additional attack vector known as blind SQL injection assistance. These verbose errors reveal structural information about the database schema, including column names and data types. This capability facilitates thorough enumeration of the database structure, allowing attackers to map out sensitive tables and fields that were previously unknown or assumed to be secure from external access.
In terms of industry standards classification, this vulnerability aligns with CWE-89 Improper Neutralization of Special Elements used in an SQL Command, commonly referred to as SQL Injection. The exploitation method involving binary search and prefix iteration is characteristic of blind SQL injection techniques often documented under CWE-204 Observable Response Discrepancy or CWE-203 Observable Behavior Difference. Additionally, the ability to extract password verifiers relates directly to CWE-522 Insufficiently Protected Credentials. From a tactical standpoint, this activity falls under MITRE ATT&CK technique T1190 Exploit Public-Facing Application and potentially T1078 Valid Accounts if the attacker leverages stolen credentials for initial access before exploiting this specific flaw.
Mitigation strategies must focus on both immediate remediation and long-term architectural improvements. The primary fix involves upgrading to Dolibarr version 24.0.0 or later, where these input validation issues have been addressed by developers through proper parameterized queries or prepared statements that separate SQL logic from data inputs. For organizations unable to upgrade immediately, implementing a Web Application Firewall with rules capable of detecting and blocking common SQL injection patterns can provide temporary protection. It is also crucial to ensure that application error handling does not expose raw database stack traces or schema details in production environments, as this aids attackers significantly during the enumeration phase. Regular security audits focusing on API endpoint inputs and strict adherence to least privilege principles for user roles will further reduce the risk surface associated with such vulnerabilities.