CVE-2026-33944 : injection SQL dans la fiche tiers de Dolibarr

Ce que dit l'avis de sécurité du projet Dolibarr

Le projet Dolibarr a publié un avis de sécurité de gravité haute, rattaché à l'identifiant CVE-2026-33944. Il décrit une injection SQL dans la classe qui gère les tiers, le fichier societe/class/societe.class.php. Le point d'entrée est le paramètre localtax1_value, alimenté par le champ lt1 du formulaire de modification d'un tiers. La valeur est insérée telle quelle dans une requête de mise à jour, sans conversion en nombre ni protection adaptée. L'avis précise que le champ jumeau, localtax2_value, présente le même défaut. Le chercheur à l'origine du signalement, Grzegorz Tworek de la société sec4check, a testé la faille sur Dolibarr 23.0.0, dans une installation standard sans module tiers ni configuration modifiée. Nous ne reproduisons ici aucun détail technique d'exploitation, volontairement. Ce qui compte pour une PME tient en une phrase : un champ de saisie ordinaire, utilisé pour les taxes locales d'un client ou d'un fournisseur, peut devenir une porte d'accès à la base de données. Vous pouvez lire l'avis complet sur la page officielle de l'avis GHSA-v5fq-cf5m-vwv7.

Qui peut déclencher la faille et avec quels droits

Cette vulnérabilité demande d'être connecté. Ce n'est donc pas une attaque anonyme depuis Internet. Mais le niveau de droits exigé est bas : l'avis indique qu'un utilisateur standard disposant de la permission de création et de modification des tiers suffit. Il n'a pas besoin d'être administrateur. Dans une PME, cette permission est souvent largement distribuée. Les commerciaux la reçoivent pour saisir leurs prospects. L'assistante administrative la reçoit pour tenir le fichier clients. Un comptable la reçoit pour corriger une adresse de facturation. Un stagiaire, un intérimaire ou un prestataire externe disposent parfois du même profil. Chacun de ces comptes devient un point d'entrée possible s'il est compromis, par exemple à la suite d'un mot de passe réutilisé ou d'un hameçonnage. Le risque vient donc autant d'un collaborateur mal intentionné que d'un compte détourné. Plus vous avez de comptes ayant ce droit, plus la surface exposée est large. Ce constat vaut pour toute instance accessible à plusieurs personnes, qu'elle soit hébergée en interne ou chez un prestataire.

Ce qu'un attaquant peut obtenir dans votre base

L'avis décrit un impact sur la confidentialité, l'intégrité et, par rebond, le contrôle de l'instance. L'attaquant peut lire des données de la base : empreintes de mots de passe, clés d'API, fichier clients et fournisseurs, factures, coordonnées bancaires. Il peut aussi modifier des enregistrements, puisque la requête concernée est une mise à jour. L'avis évoque enfin une élévation de privilèges : en récupérant des empreintes de mots de passe, un utilisateur ordinaire peut viser un compte administrateur. L'avis ajoute que l'exécution de code à distance est envisageable après cette élévation, via des fonctions réservées aux administrateurs. Concrètement, pensez à ce que contient votre Dolibarr. Les conditions de paiement négociées avec chaque client, les prix d'achat, les IBAN des fournisseurs, les contrats en cours. Une fuite de ces informations a des conséquences commerciales et, pour les données personnelles, des conséquences réglementaires. Une modification discrète d'un IBAN fournisseur peut aussi passer inaperçue pendant des semaines. C'est pour cela que l'avis est classé en gravité haute malgré le besoin d'authentification.

Quelles versions mettre à jour, et vers laquelle

L'avis fourni indique que le test a été réalisé sur la version 23.0.0. Il ne liste pas, dans l'extrait dont nous disposons, les versions corrigées. Nous ne les déduisons donc pas. La démarche raisonnable consiste à consulter la page de l'avis pour connaître la version qui contient le correctif de votre branche, puis à passer à une version publiée plus récente que celle que vous utilisez. À ce jour, les versions les plus récentes sont la 24.0.1 du 7 septembre 2026, la 24.0.0 et la 23.0.4 du 20 août 2026, la 22.0.5 du 26 mai 2026 et la 18.0.10 du 7 mai 2026. Si vous êtes sur la branche 23, la 23.0.4 est la plus récente de cette branche. Si vous êtes sur une branche plus ancienne, comparez votre numéro à cette liste. Nous avons détaillé la première version corrective de la branche 24 dans notre article sur Dolibarr 24.0.1. Pour une mise à jour de version majeure, prévoyez un test préalable sur une copie.

Les gestes à faire cette semaine

Une mise à jour ne s'improvise pas sur une instance de production. Mais certains gestes se font sans attendre et réduisent le risque pendant que vous planifiez l'opération. Commencez par savoir qui détient la permission concernée. Ensuite, vérifiez que vous maîtrisez vos sauvegardes, car une mise à jour sans retour arrière possible est une prise de risque inutile. Voici l'ordre que nous suivons chez nos clients.

• Listez les utilisateurs qui disposent du droit de créer ou modifier les tiers, et retirez-le à ceux qui n'en ont pas un besoin réel.
• Désactivez les comptes dormants : anciens salariés, stagiaires partis, prestataires dont la mission est terminée.
• Faites une sauvegarde complète de la base et du dossier documents, puis vérifiez qu'elle se restaure sur un environnement de test.
• Appliquez la mise à jour vers une version publiée plus récente que la vôtre, d'abord sur une copie, puis en production.
• Après l'opération, relisez les fiches tiers modifiées récemment et les notes privées, pour repérer toute valeur inhabituelle.

Vérifier les traces et durcir l'instance après correctif

Une fois la mise à jour passée, une question reste : la faille a-t-elle été utilisée avant ? Rien dans l'avis ne dit qu'elle l'ait été chez vous, et nous n'avons pas d'information sur une exploitation en cours. Mais la prudence impose un contrôle simple. Relisez les journaux du serveur web et les événements d'audit de Dolibarr sur la période récente. Repérez les modifications de tiers faites par des comptes qui n'en font pas d'ordinaire, ou à des heures inhabituelles. Si un doute subsiste, changez les mots de passe des comptes à privilèges et renouvelez les clés d'API stockées dans l'instance. Sur le plan structurel, appliquez le principe du moindre droit : chaque profil ne reçoit que les permissions utiles à son métier. Notre guide pour sécuriser votre instance Dolibarr en production détaille ces réglages, de l'exposition réseau à la gestion des comptes. Une instance qui n'est pas ouverte à tout Internet réduit aussi le nombre de comptes qu'un attaquant peut espérer détourner. Cette hygiène ne remplace pas le correctif, mais elle limite les dégâts du prochain défaut.

Faire appliquer le correctif sans y passer vos journées

Beaucoup de PME retardent les mises à jour faute de temps ou par crainte de casser un module spécifique. C'est compréhensible, et c'est exactement ce qui laisse des failles ouvertes des mois. Si vous préférez déléguer, notre service de maintenance couvre le suivi des avis de sécurité, les sauvegardes, les tests sur copie et la mise en production. Si vous gérez vous-même votre instance et voulez une aide pour sécuriser l'opération, le module DolicraftUpgrade sauvegarde la base et les fichiers avant chaque mise à jour et propose un retour en arrière en cas d'échec. Il couvre les versions 16 à 23 de Dolibarr. Dans les deux cas, la prochaine action est la même : relevez aujourd'hui votre numéro de version, comparez-le à la liste publiée, et fixez une date pour la mise à jour. Si vous voulez un avis sur votre situation précise, contactez notre équipe avec votre version et la liste de vos modules, et nous vous dirons quoi faire en priorité.