My accountCartFree DemoRequest a quote
Back to blog
Security5 min read

CVE-2026-23500: critical flaw in Dolibarr

A critical flaw lets someone run commands on the Dolibarr server from an administrator account. Here is what the sources say and what you should do about it.

Server in a technical room with an open padlock in front of the racks, symbolizing a security flaw

What the security advisory describes

The Dolibarr project has published an advisory rated critical, identified as CVE-2026-23500. It describes an operating system command injection, leading to remote code execution, linked to the MAIN_ODT_AS_PDF parameter. This parameter is used to convert ODT documents to PDF, for example for quotes and invoices. According to the advisory, the value saved in this parameter is neither validated nor sanitized before it is passed to the system. An authenticated administrator, or anyone who has taken control of an administrator account, can therefore make the server run arbitrary commands. The report is credited to Łukasz Rybak. We will not detail the method: it would add nothing to your defense. Keep the essentials in mind. The flaw cannot be exploited by an anonymous visitor, but it turns a compromised administrator account into a takeover of the server. You can read the full advisory on the security advisory page.

Why a flaw limited to administrators is still serious

It may look minor, since the attacker needs to be an administrator. That would be a mistake. In a small business, the administrator account is often shared, its password is old, and there is no two-factor authentication. A password reused elsewhere and leaked is enough. The advisory spells out the impact: commands run with the rights of the web server user. That makes it possible to read configuration files, and so the database credentials, to modify the application code, and even to compromise the whole system depending on how the server is set up. For a company, this means access to customers, invoices, quotes and attached documents. A flaw that requires a privileged account therefore multiplies the damage once a login has been stolen. It justifies a quick update, even if your instance is not exposed to unknown users.

Affected and fixed versions

The advisory gives version 23.0 as the fixed version. For the 18 branch, the changelog of version 18.0.9, released on April 2, 2026, mentions the fix for this advisory. You can read it on the version 18.0.9 page. For the 23 branch, versions 23.0.1 and 23.0.2 were released on April 4, 2026. According to its changelog, 23.0.2 also includes several fixes referenced as security advisories, unrelated to this one. For this branch, version 23.0.2 is the most recent and the most sensible target. The sources say nothing about branches 21 and 22 for this specific advisory. We will therefore make no claim about them. If you use one of them, check the project's advisory or ask us to review your situation. In any case, avoid staying on a version older than those cited here.

What to do today

Start by identifying your version: it appears in the Help menu, under About. Then go through the steps below, in order. They take little time and reduce the risk until the update is done.

  • Back up the database and the files, including the documents folder and your custom modules, before any operation.
  • Update to 23.0.2 if you are on the 23 branch, or to 18.0.9 if you are on the 18 branch.
  • List the administrator accounts and delete those that are no longer needed.
  • Change the administrator passwords, especially if they are old or shared between several people.
  • In the configuration, check that the value of the MAIN_ODT_AS_PDF parameter matches what you set yourself, or that it is absent.

Checking whether someone has already tampered with your configuration

The update fixes the defect, but it does not erase a possible past intrusion. If your instance is reachable from the Internet and your administrator accounts have weak passwords, take ten minutes to check. First look at the value of the MAIN_ODT_AS_PDF parameter in the complementary configuration. It should contain only what you or your integrator put there, nothing else. Then go through the login logs to spot administrator access at unusual hours or from unknown addresses. If anything looks abnormal, change the database credentials and those of the service accounts, then have the server examined. Our article on securing a Dolibarr instance in production covers the basic protections: two-factor authentication, access filtering, file permissions and tested backups.

Updating without interrupting your business

A corrective update, from 23.0.x to 23.0.2 or from 18.0.x to 18.0.9, is in principle a limited change. It still needs preparation: backup, test on a copy, then rollout to production outside invoicing hours. If you have modules maintained in-house or customized document templates, check them on the copy before switching. Our DolicraftUpgrade module automates the prior backup, the checks and the rollback if something fails, for versions 16 to 23. Our Dolibarr maintenance offer also covers this version tracking for companies that prefer not to handle it. If you would like us to check your version, your configuration and your administrator accounts, contact us with the address of your instance and its current version. We will reply with the actions to take.

Need help with Dolibarr?

Our team of Dolibarr experts is available to support you in your projects: implementation, migration, custom module development and training.