Case-sensitive denylist bypass in Dolibarr exposes password hashes

Dolibarr 24.0.0 before 24.0.1 contains a case-sensitive denylist bypass vulnerability in the sqlfilters API query parameter that allows authenticated attackers to recover protected database fields by supplying uppercase variants of denylist-protected field names. Attackers can exploit the case-insensitive database column resolution against the case-sensitive denylist check in the core library to use prefix-matching predicates as a boolean oracle and extract full password hashes for any user account, including administrators.

• Dolibarr: version 24.0.0 is marked affected when the version is less than 24.0.1, using semver.
• The record sets the default status to unaffected outside the supplied affected range.
• 24.0.1 is the release linked to the patch and is the upgrade target supported by the available evidence. The status of parallel or later branches is not independently confirmed in the reviewed data.

The flaw is in the sqlfilters API query parameter, where field predicates are processed by the core library. The denylist check in that library was case sensitive, while database column resolution was case insensitive. As a result, uppercase variants of protected field names could pass the denylist check while still resolving to sensitive columns. Prefix-matching predicates could then be used as a boolean oracle to infer and recover complete password hashes for user accounts, including administrators. Exploitation requires authenticated network access; the available evidence does not identify the exact endpoint, minimum application role, database engine, or whether every deployment configuration exposes the affected API.

• The attacker needs an authenticated account and network access to the affected API surface.
• The record describes low attack complexity and no requirement for interaction from another user.
• The issue enables attacker-controlled reads through crafted queries, but is not described as directly modifying data or disrupting service.
• The normalized record marks public_exploit as false and does not mark the vulnerability as known exploited. This does not prove that no unreported or private exploitation exists.

The flaw allows an authenticated account to read database fields protected by the denylist and may recover complete password hashes for any user, including administrators. The direct technical outcome described is loss of confidentiality in the vulnerable system; there is no evidence that the issue directly changes data or affects availability. Obtained hashes may enable offline cracking or credential abuse on other systems if users reuse passwords, but that outcome depends on password policy and is not confirmed by the record. The flaw does not itself grant administrator privileges, although disclosure of administrator hashes increases the risk of takeover if credentials are recovered or reused.

• An authenticated attacker may recover protected database fields, including password hashes for user and administrator accounts.
• Loss of password-hash confidentiality can create follow-on risk from offline cracking or password reuse, depending on password strength and reuse. This is a possible consequence, not a confirmed breach outcome.
• The issue is not described as enabling data modification or service disruption, but exposed credentials may increase the risk of unauthorized access to other systems if users reuse passwords.
• Because authentication is required, the exposure depends on which accounts can reach the API and what data the API returns in a particular deployment.

1. Upgrade Dolibarr to 24.0.1, the release linked to the change that makes operand-name control case insensitive.
2. After upgrading, verify that the deployed core library contains the denylist handling change and redeploy or restart application components according to normal operating procedures.
3. Inventory authenticated accounts that could reach the API and review query activity from the period when the system was in the affected range.
4. Because password hashes may have been readable, consider forced password resets, prioritizing administrator accounts, and review for password reuse. This is precautionary action based on the data exposure impact, not a recovery step explicitly stated in the advisory.
5. If an upgrade is not immediately possible, the record provides no specific temporary mitigation. Do not treat application-side uppercase filtering or proxy filtering as a confirmed substitute for the code fix.

• Inventory Dolibarr deployments and identify the running version, especially systems that expose an API supporting the sqlfilters parameter.
• Confirm that servers have been upgraded to the release named in remediation, rather than checking only a source tree or package cache.
• Review reverse proxy, web server, and application logs for repeated authenticated requests using sqlfilters, unusual uppercase field names, or repeated prefix-matching predicates. This is precautionary review guidance, not a confirmed IOC.
• Check whether low-privilege accounts made unusually large numbers of read queries against sensitive data.
• If activity matches the described behavior, preserve relevant logs and assess password hashes for all accounts that may have been readable as exposed data.