CVE-2026-33944: SQL injection in the Dolibarr third-party record

What the Dolibarr project's security advisory says

The Dolibarr project has published a high-severity security advisory under the identifier CVE-2026-33944. It describes an SQL injection in the class that manages third parties (customers, suppliers and prospects), the file societe/class/societe.class.php. The entry point is the localtax1_value parameter, fed by the lt1 field of the form used to edit a third party. The value is inserted as is into an update query, with no conversion to a number and no suitable protection. The advisory states that the twin field, localtax2_value, has the same flaw. The researcher who reported it, Grzegorz Tworek of the company sec4check, tested the flaw on Dolibarr 23.0.0, on a standard installation with no third-party module and no modified configuration. We deliberately give no technical exploitation details here. What matters for an SME fits in one sentence: an ordinary input field, used for the local taxes of a customer or supplier, can become a way into your database. You can read the full advisory on the official page of advisory GHSA-v5fq-cf5m-vwv7.

Who can trigger the flaw, and with which rights

This vulnerability requires a logged-in user. It is not an anonymous attack from the Internet. But the level of rights required is low: the advisory says a standard user with the permission to create and edit third parties is enough. The user does not need to be an administrator. In an SME, this permission is often widely granted. Sales reps get it to enter their prospects. The administrative assistant gets it to maintain the customer file. An accountant gets it to correct a billing address. An intern, a temp or an external contractor sometimes has the same profile. Each of these accounts becomes a possible entry point if it is compromised, for example after a reused password or a phishing email. The risk therefore comes as much from an ill-intentioned colleague as from a hijacked account. The more accounts hold this right, the wider the exposed surface. This applies to any instance that several people can access, whether it is hosted in-house or by a provider.

What an attacker can get from your database

The advisory describes an impact on confidentiality, integrity and, indirectly, control of the instance. The attacker can read data from the database: password hashes, API keys, customer and supplier files, invoices, bank details. The attacker can also modify records, since the query involved is an update. Finally, the advisory mentions privilege escalation: by retrieving password hashes, an ordinary user can aim for an administrator account. It adds that remote code execution is conceivable after this escalation, through functions reserved for administrators. In practical terms, think about what your Dolibarr holds. The payment terms negotiated with each customer, purchase prices, supplier IBANs, ongoing contracts. A leak of this information has commercial consequences and, for personal data, regulatory ones. A discreet change to a supplier IBAN can also go unnoticed for weeks. That is why the advisory is rated high severity despite the need for authentication.

Which versions to update, and to which one

The advisory we have states that the test was carried out on version 23.0.0. In the extract available to us, it does not list the fixed versions. We therefore do not infer them. The reasonable approach is to check the advisory page to find the version containing the fix for your branch, then move to a published version newer than the one you run. As of today, the most recent versions are 24.0.1 of 7 September 2026, 24.0.0 and 23.0.4 of 20 August 2026, 22.0.5 of 26 May 2026 and 18.0.10 of 7 May 2026. If you are on branch 23, 23.0.4 is the most recent for that branch. If you are on an older branch, compare your number with this list. We covered the first corrective release of branch 24 in our article on Dolibarr 24.0.1. For a major version upgrade, plan a test on a copy first.

What to do this week

An update is not something to improvise on a production instance. But some actions can be taken right away and reduce the risk while you plan the operation. Start by finding out who holds the permission concerned. Then check that your backups are under control, because an update with no way back is an unnecessary risk. Here is the order we follow with our clients.

• List the users who have the right to create or edit third parties, and remove it from those who have no real need for it.
• Disable dormant accounts: former employees, interns who have left, contractors whose assignment is over.
• Make a full backup of the database and the documents folder, then check that it restores on a test environment.
• Apply the update to a published version newer than yours, first on a copy, then in production.
• After the operation, review recently modified third-party records and private notes, to spot any unusual value.

Check the traces and harden the instance after the fix

Once the update is done, one question remains: was the flaw used before? Nothing in the advisory says it was on your instance, and we have no information about ongoing exploitation. But caution calls for a simple check. Review the web server logs and the Dolibarr audit events for the recent period. Look for third-party changes made by accounts that do not usually make them, or at unusual hours. If doubt remains, change the passwords of privileged accounts and renew the API keys stored in the instance. At the structural level, apply the principle of least privilege: each profile receives only the permissions its job requires. Our guide to securing your Dolibarr instance in production details these settings, from network exposure to account management. An instance that is not open to the whole Internet also reduces the number of accounts an attacker can hope to hijack. This hygiene does not replace the fix, but it limits the damage from the next flaw.

Getting the fix applied without losing your days

Many SMEs delay updates for lack of time or for fear of breaking a custom module. That is understandable, and it is exactly what leaves flaws open for months. If you prefer to delegate, our maintenance service covers monitoring of security advisories, backups, tests on a copy and the move to production. If you manage your instance yourself and want help making the operation safer, the DolicraftUpgrade module backs up the database and files before each update and offers a rollback if it fails. It covers Dolibarr versions 16 to 23. In both cases, the next action is the same: note your version number today, compare it with the published list, and set a date for the update. If you want advice on your specific situation, contact our team with your version and the list of your modules, and we will tell you what to do first.