Dolibarr third-party update SQL injection lets authenticated users read sensitive data (CVE-2026-33944)

What happened

An attacker with a Dolibarr account that can create or edit Third Party records can inject SQL in the Third Party company update. The application puts the localtax1_value and localtax2_value properties into an SQL UPDATE statement without numeric conversion or sanitisation, so crafted lt1 or lt2 POST parameters become SQL code.

The result is CWE-89 SQL injection over the network with low privileges and no user interaction. A successful attacker can read sensitive database information, including password hashes, API keys and business data, or modify third-party records. The CVSS score is 8.8 high. No exploitation in the wild is currently reported.

Who is affected

Affected releases are Dolibarr before 22.0.5 and Dolibarr 23.0.0 through 23.0.1. The vulnerable path is the Third Party company update functionality, so the practical exposure is a Dolibarr instance where accounts with Third Party create or edit permission can reach the web interface. Typical deployments are self-hosted ERP/CRM systems that hold customer and supplier records; internet-facing instances should be checked first.

What to do now

1. Confirm whether your Dolibarr version is before 22.0.5 or in the 23.0.0–23.0.1 range.
2. Review accounts that hold Third Party create or edit permission and remove or suspend any that are not essential.
3. The vendor advisory does not list a workaround. Until a fix is in place, restrict network access to the Dolibarr web interface, especially if it is internet-facing.
4. Apply the vendor fix once published; the CVE record cites fixed releases 22.0.5 and 23.0.2. Check the vendor advisory before deploying.

How to detect it

Because the vulnerable path is a SQL injection in Third Party update requests, review web server logs for unusual lt1 or lt2 values in POST requests to that endpoint, particularly long strings, quotes or SQL keywords. Enable or review database audit logs for unexpected UPDATE statements against third-party tables, such as mass changes to local tax fields or company records that did not come through normal workflow.

Beyond the patch

Beyond patching, this is the sort of input-validation flaw that Implementation & Assessment Services penetration testing and hardening finds before an authorised user can abuse it in production. Because Dolibarr is an open-source third-party ERP/CRM application with its own release cadence, Supply Chain Defense & Third-Party Risk is where you track the version you run and the vendor's patch timing so this exposure window closes on schedule.