Faille critique dans Dolibarr : les champs calculés permettent d'exécuter du code

Ce que dit l'avis de sécurité

Le projet Dolibarr a publié un avis de sécurité classé critique sur la fonction dol_eval_standard(), qui évalue les valeurs des champs complémentaires calculés. Le bac à sable censé limiter ce qu'une formule peut faire est incomplet. Un administrateur peut y glisser une expression qui contourne les contrôles et mène à l'exécution de code sur le serveur. Le score CVSS 3.1 est de 9.1. L'avis rapporte que l'attaque demande des droits d'administrateur, mais que la formule s'exécute pour chaque utilisateur qui ouvre la fiche concernée. Le défaut a été découvert fin mars 2026 par un chercheur en sécurité, crédité dans l'avis, puis signalé à l'équipe de sécurité de Dolibarr. Nous ne détaillons volontairement pas la méthode : seule compte pour vous la conduite à tenir.

Versions concernées et version corrigée

L'avis confirme la faille sur Dolibarr 23.0.0. Il indique qu'elle touche probablement toutes les versions qui utilisent dol_eval_standard() avec le chemin par défaut, celui où le paramètre dolibarr_main_restrict_eval_methods est renseigné. La version corrigée mentionnée est la 23.0.3, publiée le 18 mai 2026. Depuis, plusieurs versions sont sorties : la 23.0.4 et la 24.0.0 le 20 août 2026, puis la 24.0.1 le 7 septembre 2026. Si vous êtes en 23.0.0, 23.0.1 ou 23.0.2, vous êtes exposé. Pour les autres branches, l'avis ne donne pas de liste précise : vérifiez que vous êtes sur la dernière version corrective de votre branche plutôt que de supposer que vous n'êtes pas concerné.

Pourquoi un risque réservé aux administrateurs compte quand même

On peut être tenté de minimiser : il faut être administrateur. En pratique, ce prérequis est moins rassurant qu'il n'y paraît. Un compte administrateur dont le mot de passe a fuité, un prestataire dont les accès n'ont jamais été retirés, un poste compromis : chacun suffit à rendre le scénario réaliste. Une fois la formule en place, l'avis souligne qu'elle agit à chaque consultation de la fiche, par n'importe quel utilisateur. Les conséquences décrites vont de l'exécution de code à la lecture de fichiers du serveur, dont le fichier de configuration contenant les accès à la base de données. Pour une PME, cela signifie un accès potentiel à l'ensemble des données clients, factures et pièces comptables.

Mettre à jour : la mesure prioritaire

La réponse est simple : passer sur une version corrigée. Si vous êtes en branche 23, la 23.0.4 contient le correctif de la 23.0.3. Si vous avez déjà migré, la 24.0.1 est la plus récente publiée à ce jour. Avant toute opération, sauvegardez la base de données et le répertoire documents, puis testez la mise à jour sur une copie. Notre article sur la première version corrective de Dolibarr 24 détaille ce que cette version apporte. Si vous préférez déléguer, notre service de maintenance prend en charge les mises à jour de sécurité, et le module DolicraftUpgrade propose une mise à jour avec sauvegarde automatique pour les versions 16 à 23.

Vérifier votre instance en attendant ou après la mise à jour

Une mise à jour ferme la porte, mais ne dit pas si quelqu'un l'a déjà franchie. Prenez un moment pour contrôler ce qui existe déjà. Cette revue est rapide et utile même sans soupçon particulier.

• Listez les comptes administrateurs et supprimez ceux qui ne sont plus nécessaires, puis changez les mots de passe des autres.
• Ouvrez la configuration des attributs complémentaires de chaque module et relisez toutes les valeurs calculées : toute formule que personne ne reconnaît doit être examinée.
• Recherchez dans le répertoire custom des fichiers récents que vous n'avez pas déposés, en particulier avec l'extension php.
• Vérifiez que le serveur web n'a pas plus de droits d'écriture que nécessaire sur l'arborescence de l'application.
• Activez l'authentification renforcée pour les administrateurs lorsque votre configuration le permet.

Réduire la surface d'attaque durablement

Cette faille rappelle un principe : les droits d'administration d'un ERP équivalent à un accès au serveur. Limitez-les à deux ou trois personnes identifiées, séparez les comptes de travail quotidien des comptes d'administration et retirez les accès d'un prestataire dès la fin de sa mission. Côté infrastructure, un serveur qui ne peut pas écrire partout dans le répertoire web limite ce qu'un code malveillant pourrait déposer. Nous avons rassemblé ces pratiques dans notre guide pour sécuriser Dolibarr en production. Elles ne remplacent pas le correctif, mais elles réduisent l'impact de la prochaine faille, quelle qu'elle soit.

Votre prochaine action

Ouvrez dès aujourd'hui la page d'information de votre instance Dolibarr et notez le numéro de version. Si c'est 23.0.0, 23.0.1 ou 23.0.2, planifiez la mise à jour cette semaine, sans attendre la prochaine fenêtre de maintenance habituelle. Si vous ne disposez pas de l'environnement de test ni du temps nécessaire, contactez-nous : nous contrôlons votre version, relisons vos champs calculés et réalisons la mise à jour avec sauvegarde préalable. Les références officielles restent l'avis de sécurité publié par le projet Dolibarr, à consulter pour suivre d'éventuelles précisions.