What is the CVSS score of CVE-2026-33944?

CVE-2026-33944 has a CVSS 3.1 base score of 8.8 (High). CVSS vector: CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H.

How to fix or mitigate CVE-2026-33944?

Within 24 hours, restrict access to the Third Party Create/Edit permission to only essential personnel and monitor for suspicious database queries or unauthorized changes. Within 7 days, apply any vendor-released patch or update to a fixed version once available, and if not available, implement a web application firewall (WAF) rule to block malicious payloads targeting the lt1/localtax1_value and lt2/localtax2_value parameters. Within 30 days, conduct a thorough review of user permissions and database activity logs, and plan for a full upgrade to a patched version as soon as the vendor releases it.

Dolibarr ERP/CRM CVE-2026-33944

HIGH

SQL Injection (CWE-89)

2026-10-27 https://github.com/Dolibarr/dolibarr

GHSA-v5fq-cf5m-vwv7

PHP Privilege Escalation Docker SQLi

8.8

CVSS 3.1 · GitHub Advisory

View

Attack ChainAIDerived

Hypothetical attack flow derived from CVE metadata – not a confirmed exploit chain

Access

Authenticate as low-privilege Third Party editor
Delivery

Open company edit form
Exploit

Inject SQL via POST lt1 parameter
Execution

Bypass GET-only WAF, run arbitrary SELECT
Persist

Exfiltrate admin MD5 hash to notes field
Impact

Crack hash and escalate to admin

Vulnerability Assessment

Weakness	CWE CWE-89 OWASP Top 10:2025 A05:2025 - Injection ASVS 5.0 V1 - Encoding and Sanitization Parameterized queries, prepared statements MITRE ATT&CK 2 techniques across 2 tactics: Initial Access, Persistence The technique list with ATT&CK links and the kill-chain view is part of the Basic plan and up. Sign in to read
Exploitation Conditions	Requires an authenticated session as a user holding the standard 'Third Parties: Create/Edit' permission (not admin). The attacker submits a POST request to societe/card.php with action=update and the lt1 (localtax1_value) parameter - or lt2/localtax2_value - which is taken from GETPOST('lt1','alpha'), trimmed but never cast to float or escaped, then concatenated into the UPDATE statement in an unquoted numeric context; a second SET clause can be appended (e.g. lt1=1,note_private=(SELECT ...)). Limiting/enabling factors: exploitation works against a default installation (official Docker image, no custom modules, no config changes) so no special product feature or non-default setting is needed; the only real gate is possession of the low-privilege edit permission. Notably, Dolibarr's WAF (waf.inc.php) inspects only GET parameters, so delivering lt1 via POST deliberately evades it - meaning WAF deployment does not mitigate this.
Impact	This is a genuine, actionable priority rather than an inflated CVSS score. The signals are internally consistent: the CVSS:3.1 vector (AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H, base 8.8) describes a network-reachable, low-complexity, low-privilege SQL injection, and the GHSA advisory supplies a complete, reproducible proof-of-concept (Burp steps plus a working curl request) that demonstrates arbitrary read and write against a default Dolibarr v23.0.0 install. The vuln.today decision label is 'this_week', which aligns with a serious-but-not-emergency flaw: it requires authentication (PR:L - a standard 'Third Party: Create/Edit' user, not admin), which caps the blast radius to insiders or attackers who already hold low-privilege credentials, and it is not listed in CISA KEV, indicating no confirmed active exploitation yet. No EPSS score was provided in the input, so probabilistic exploitation likelihood cannot be quantified here. The critical aggravating factors are that no patch exists (advisory states 'not yet patched', vulnerable <= 23.0.0) and that successful injection yields unsalted MD5 password hashes enabling privilege escalation to admin, after which RCE becomes plausible via admin-only modules - so while the raw vector requires only low privilege, the realistic end-state is full compromise. Net: a real, near-term priority for any exposed Dolibarr instance, tempered only by the authentication requirement and the current absence of in-the-wild exploitation evidence.
Exploit ScenarioDerived	An authenticated user holding the standard 'Third Party: Create/Edit' permission edits any company record and submits the update form with the POST parameter lt1 set to '1,note_private=(SELECT pass_crypted FROM llx_user WHERE rowid=1)', injecting an additional SET clause into the UPDATE statement and exfiltrating the admin's MD5 password hash into a readable Notes field. Because the value is concatenated into a numeric SQL context with no quoting, cast, or escaping - and Dolibarr's WAF only inspects GET parameters - the attacker needs no filtered characters and the POST bypasses the WAF entirely. A detailed, working public PoC (curl command and Burp reproduction) is published in the GHSA advisory, and the low attack complexity (AC:L) means exploitation is reliable once valid low-privilege credentials are obtained.

This Week Schedule remediation this week. Why: HIGH severity (CVSS 7.0-8.9).

No patch listed yet

Get an e-mail when this CVE is exploited, patched or re-scored. Free account.

Alert me

AnalysisAIv1 – Oct 28, 2026

Authenticated SQL injection in Dolibarr ERP/CRM through version 23.0.0 lets any user holding the standard 'Third Party: Create/Edit' permission - not just an administrator - read or rewrite arbitrary database content. The unescaped lt1/localtax1_value (and lt2/localtax2_value) POST parameter is concatenated into an UPDATE statement in an unquoted numeric context, so an attacker can append a second SET clause and copy a target value such as a user's password hash into a field they can then read, potentially escalating to admin and onward to RCE via admin-only modules. The vendor advisory GHSA-v5fq-cf5m-vwv7 ships a complete reproduction including working request payloads; no confirmed active exploitation (CISA KEV) has been reported, and no fixed release is listed yet - the package data records composer/dolibarr/dolibarr as vulnerable at <= 23.0.0 with 'not yet patched'. With a CVSS 3.1 vector of AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H (8.8) and a this_week decision label, this is a genuine, actionable priority rather than an inflated CVSS score.

RemediationAI

No vendor-released patch is identified at time of analysis: the package data lists composer/dolibarr/dolibarr as vulnerable at <= 23.0.0 with 'not yet patched', so there is no fixed version to upgrade to yet - track GHSA-v5fq-cf5m-vwv7 at https://github.com/Dolibarr/dolibarr/security/advisories/GHSA-v5fq-cf5m-vwv7 and https://github.com/advisories/GHSA-v5fq-cf5m-vwv7 for the release that carries the fix. The reporter's proposed code change is to cast the value both on assignment (line 1528, (float) price2num(trim($this->localtax1_value)) and the equivalent for localtax2_value at line 1529) and at the SQL sink (line 1672, ",localtax1_value =".((float) $this->localtax1_value), with the same treatment for lines 1682); because the sinks are in an unquoted numeric context, a float cast or $db->escape() at the sink is what closes the injection. Deploying or tuning a WAF will not mitigate this: Dolibarr's waf.inc.php inspects only GET parameters, and the exploit is delivered as a POST body, so any virtual patch must be a custom rule that inspects POST request bodies for the lt1/lt2 parameters - with the trade-off of added latency, false positives on legitimate tax-value edits, and dependency on the rule being maintained outside the application. The only remaining gate is the low-privilege 'Third Parties: Create/Edit' permission, so restricting that right to staff who genuinely maintain company records reduces exposure, at the cost of blocking normal data-entry workflows for the affected users; note that this permission is a standard role and revoking it broadly may not be operationally feasible. Because the injection permits writing arbitrary SET clauses, defenders should additionally treat the Dolibarr database as potentially tampered with until the fix is applied.

Affected Packages

composer dolibarr/dolibarr no fix

Source: OSV (Open Source Vulnerabilities)

Affects your stack

Affects 1 package in composer

Checking this CVE against your own stacks and servers is part of the Basic plan and up.

Technical ContextAI · show details

The flaw is a classic CWE-89 improper neutralization of SQL syntax in PHP, inside Dolibarr's Third Party model class (societe/class/societe.class.php). At line 1672 the object property is appended to the UPDATE statement as ",localtax1_value =".$this->localtax1_value with no quoting, casting, or parameter binding; localtax2_value at line 1682 is identical. The value originates from GETPOST('lt1','alpha') in societe/card.php, and the only transformation applied is trim() - the 'alpha' filter removes HTML tags and double quotes but leaves parentheses, commas, single quotes and SQL keywords intact. Because the sink sits in an unquoted numeric SQL context, none of the filtered characters are even required: a payload such as "1,note_private=(SELECT pass_crypted FROM llx_user WHERE rowid=1)" rides along as an additional assignment in the same UPDATE, and a bare "3+4" is evaluated by the database engine (stored as 7.0000), which the reporter used as arithmetic confirmation. Adjacent fields such as localtax1_assuj are correctly cast to (int), showing the omission is localized. The published reproduction was validated on Dolibarr v23.0.0 from the official Docker image against MariaDB 10.11 with no custom modules or configuration changes, so no non-default feature is a prerequisite. Dolibarr's WAF (waf.inc.php) only pattern-matches SQL injection in GET parameters, so delivering lt1 in the POST body bypasses it by design. The affected distribution is tracked as package composer/dolibarr/dolibarr, vulnerable through 23.0.0.

Know when PHP gets its next vulnerability

Watch products and get an email when something new is published
Check this CVE against your own stack and servers
Exploit and PoC references, threat intelligence from 22 sources

Continue with Google Continue with GitHub

No credit card · 7-day full trial

Severity by source

GitHub Advisory PRIMARY 8.8 HIGH

AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H

vuln.today AI 8.8 HIGH

Network-reachable web form, low complexity and no user interaction, but a standard edit permission is required (PR:L); injection allows arbitrary DB read, record modification, and data destruction (C:H/I:H/A:H).

3.1 AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H

4.0 AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N

Primary rating from GitHub Advisory.

CVSS VectorGitHub Advisory

Attack Vector

Network

Attack Complexity

Low

Privileges Required

Low

User Interaction

None

Scope

Unchanged

Confidentiality

High

Integrity

High

Availability

High

DescriptionGitHub Advisory

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):

php

  $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=1
lt1=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):

Figure 2 - Burp Suite Repeater: full POST request headers and HTTP 302 Found response:

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:

bash

  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

php

  // 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 (grzegorz.tworek@sec4check.pl)

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.

Technical POC Analysis

CWE-89 (SQL injection).

Full technical POC analysis - root cause, step-by-step exploitation and patch breakdown - is part of the Pro and Business plans.

Executive ViewAI

Why It Matters

Dolibarr ERP/CRM version 23.0.0 and earlier contain an authenticated SQL injection vulnerability that allows any user with standard 'Third Party: Create/Edit' permissions to read or modify arbitrary database contents, including password hashes. This could lead to privilege escalation and potentially remote code execution, impacting all organizations using the affected Dolibarr versions. Leadership should prioritize remediation due to the high potential for data breach and system compromise.

Business Impact: High

Compensating Controls

No vendor-released patch identified at time of analysis. Interim mitigations include restricting the 'Third Party: Create/Edit' permission to trusted users, deploying WAF rules to detect and block SQL injection attempts, and monitoring database logs for anomalous activity.

Threat Intelligence Overview

Prevalence

Medium

popular open-source ERP/CRM, moderate SMB and enterprise footprint

Threat Intel

1 source

Data Quality

3 sources

Confidence: Low

NVD

CVE.org GHSA

GitHub

How this decision was reached

The engine reads each signal below and applies a fixed list of rules from top to bottom. The first rule that matches sets the recommended action – like a statement, every line is shown.

SignalValue

Severity HIGH

CISA KEV No

Public POC No

EPSS N/A

Patch available No

Active threat No

Deciding rule

HIGH severity (CVSS 7.0-8.9)

What every action level means

Emergency Immediate action required. Criteria: CRITICAL + in CISA KEV (actively exploited) without patch, OR CRITICAL + EPSS > 30% without patch, OR CRITICAL + active threat signals without patch.

Act Now Prioritize within 24-48h. Criteria: in KEV with patch available, OR CRITICAL + public POC, OR HIGH + EPSS > 10%, OR CRITICAL + active threat, OR any CRITICAL severity.

This Week Schedule remediation this week. Criteria: HIGH severity (CVSS 7.0-8.9). Patch within normal change window.

This Month Plan within 30 days. Criteria: MEDIUM severity (CVSS 4.0-6.9), lower exploitation probability. Include in regular patch cycle.

Monitor Track and reassess. Criteria: LOW severity (CVSS 0.1-3.9), minimal exploitation risk. No immediate action needed.

SSVC AssessmentENISA

SSVC Decision· derived

Scheduled

Exploitation· derived

None

System Exposure· derived

Open

Automatable· derived

Human Impact

High

Priority Score

Low Medium High Critical

KEV: 0

EPSS: 0

CVSS: +44

PoC: 0

Weaponized: 0

Threat intel: 0

Gov advisory: 0

Attack Technique

SQL Injection HIGH

SQL injection exploits the way applications construct database queries by mixing user input directly into SQL statements.

Privilege Escalation HIGH

Privilege escalation occurs when an attacker leverages flaws in access control mechanisms to gain permissions beyond what they were originally granted.