CVE-2026-34036: a file-reading flaw in Dolibarr

What the security advisory describes

A security advisory published on the Dolibarr GitHub repository describes an authenticated local file inclusion in the AJAX entry point selectobject.php. It carries the identifier CVE-2026-34036. Its severity is rated medium. The researcher says they observed it on Dolibarr 22.0.4. The principle: a logged-in user, even without any specific permission, can make the server read files that are not PHP. The advisory gives configuration files, backups and logs as examples. The content of these files can then appear in the server response. We do not detail the method here, and you do not need it to act. Keep the essential point: a valid account is enough, not an administrator account. For a small business, that includes accounts of employees, interns, contractors and former staff whose access was never closed.

Why an ordinary account is enough

The advisory identifies two flaws that add up. First, the script loads a file before checking the user's permissions. Second, the central access control function, restrictedArea(), lets the request through when no feature is specified, instead of refusing it. As a result, the request ends normally and no authorization error is returned. The advisory states that PHP files trigger a fatal error before their code is displayed. Text files, however, can be returned: web server configuration files, SQL exports, JSON files. The risk is therefore about confidentiality. The advisory mentions the disclosure of infrastructure details, installed versions, forgotten logs or database backups, which could help prepare other attacks. An export left in a folder the server can reach then becomes a real issue.

Versions: what the sources say

Let us be precise about what we know. The advisory mentions a test on Dolibarr 22.0.4, released on 24 December 2025. In the extract we have, it does not list the fixed versions or all the affected versions. So we cannot tell you that a specific version contains the fix. The latest versions published to date are 23.0.0 of 5 March 2026 and 22.0.4. For branch 21, the latest is 21.0.4, and for branch 18, 18.0.8. The sensible approach is to read the official advisory, linked below, then check in the release notes which release includes the fix for your branch. If in doubt, treat your instance as exposed until you have confirmed otherwise. If you run an old version, this alert adds to other reasons to update.

What you can do today

Even without knowing the exact fixed version, several actions reduce the risk right away. They do not replace the update, but they limit what an ordinary account could read. Start with what depends on you: user accounts and server content.

• Disable unused accounts, especially those of former employees and of contractors whose assignment has ended.
• Search the server for backups, SQL exports, archives and logs left inside the application directory tree, and move them outside the web root.
• Check who has an account and why, then remove access that is no longer justified.
• Read the official advisory and the release notes to identify the release that fixes the flaw on your branch.
• Plan the update on a test environment before applying it to production.

Updating without taking risks

A security update needs preparation, even when it is urgent. Make a full backup of the database and files, including the documents folder and your custom modules. Then test on a copy: login, creating a quote, generating a PDF, how your modules behave. If you are on an old major version, jumping straight to the latest may need more preparation, especially for external module compatibility. Our free, open source module DolicraftUpgrade automates the backup before the operation, the preliminary checks and the rollback if something fails, for Dolibarr versions 16 to 23. You can find its page at DolicraftUpgrade. For the context of the latest major version, see also our article on what is new in Dolibarr 23. A good habit: update the test copy first, and only then production.

Hardening your instance beyond this fix

This flaw is a reminder of a simple principle: a sensitive file should not sit where the application can read it without need. A well-kept instance limits the damage even when a vulnerability appears. Store backups outside the application directory tree. Protect the configuration folder. Apply the principle of least privilege, with separate accounts for each role. Watch the access logs for unusual requests to AJAX entry points. We covered these measures in our article on securing your Dolibarr instance in production. They do not replace the update, but they reduce what a malicious or compromised account could obtain. If your instance is reachable from the Internet, these checks are even more useful. An instance limited to an internal network or a VPN reduces exposure, without removing it.

Next step: check your version

Open your instance, note the version displayed and compare it with the releases listed above. Then read the official security advisory to check whether your branch is affected and which version fixes it. If you lack time or a test server, we can handle the update and the module checks as part of our maintenance service. For a diagnosis of your instance, you can also write to us through the contact page. Tell us your Dolibarr version, your type of hosting and the list of your external modules. With these three items, we can quickly tell you what to do and in what order.