Retour sur une folle journée 21-10-2026

Le 21 octobre 2026, une faille de sécurité a été découverte dans le langage PHP utilisé par 70% des sites Web dans le monde entier. Dolibarr étant écrit en PHP, les services proposés sont donc impactés. Comme tous les professionnels Dolibarr, Tiaris a été mobilisé pour réagir à cette urgence.

Nous vous proposons ci-dessous un résumé de cette journée faite par l’IA (Mistral).

Faille PHP du 21 octobre 2026 : ce qu’il faut retenir — et ce que cela change pour votre Dolibarr

Ce qui s’est passé

Le mercredi 21 octobre 2026, le monde du web a connu l’un des plus importants incidents de sécurité de ces dernières années. Deux failles critiques, surnommées PHP2Shell par les experts (référencées CVE-2026-109618 et CVE-2026-109619), ont été corrigées d’urgence dans PHP, le langage informatique qui fait fonctionner environ 70 % des sites web dans le monde : boutiques en ligne, sites institutionnels, outils de gestion… et votre ERP Dolibarr.

Ce qui rend l’affaire exceptionnelle, c’est d’abord l’ampleur : toutes les versions de PHP de 5.4 à 8.5 étaient concernées, soit potentiellement des millions de serveurs (22 millions de plateformes exposées selon Palo Alto Networks). C’est ensuite la façon dont ces failles ont été découvertes : par des intelligence artificielles, lors d’audits menés par les sociétés de cybersécurité Wiz (filiale de Google) et Calif, avec le concours des modèles d’IA d’OpenAI. La gravité a été évaluée à 9,2 sur 10 sur l’échelle de sévérité internationale (CVSS), un niveau dit « critique ».

À la suite de l’annonce, de très nombreux sites ont été volontairement mis hors ligne par précaution, le temps d’appliquer les correctifs : en France, les sites de toutes les préfectures, de plusieurs ministères (Culture, Écologie), celui des impôts, et même des médias et grandes entreprises comme Renault. Des mesures similaires ont été prises au Royaume-Uni, en Allemagne, en Belgique, aux Pays-Bas, au Danemark et en Finlande. L’agence française de sécurité informatique (Anssi) et son centre d’alerte CERT-FR ont recommandé de déconnecter les serveurs non encore mis à jour ; la NSA américaine a tenu le même langage.

Pourquoi c’est grave, en termes simples

Ces deux failles permettaient à un attaquant, sans mot de passe et sans identification, de :

  • Exécuter du code à distance sur le serveur, c’est-à-dire prendre littéralement le contrôle de la machine qui héberge le site ;
  • Accéder aux données stockées sur le serveur ;
  • Provoquer des interruptions de service (déni de service), rendant le site indisponible.

Concrètement : imagineriez-vous que n’importe qui, dans le monde, puisse ouvrir la porte de votre coffre-fort sans clé ? C’est ce que ces failles rendaient possible sur un serveur non corrigé. Et quelques jours après la publication des correctifs, des attaques réelles ont été observées : l’agence américaine CISA a officiellement inscrit ces failles le 26 octobre dans son catalogue des vulnérabilités activement exploitées par des pirates.

Les correctifs appliqués

La réaction a été rapide et bien orchestrée. Le 20 octobre au soir, l’équipe de PHP a prévenu la communauté qu’une mise à jour critique sortirait le lendemain. Les correctifs ont été publiés le 21 octobre 2026 à 14 h 00 UTC (16 h 00 heure de Paris), dans les versions :

  • PHP 8.5.12
  • PHP 8.4.27
  • PHP 8.3.36
  • PHP 8.2.35

Et pour les versions plus anciennes, notamment PHP 7 ?

Les branches PHP 7.4, 8.0 et 8.1 ne sont officiellement plus maintenues par le projet PHP, mais cette situation concernait tellement de serveurs que des correctifs ont tout de même été publiés pour ces versions :

  • Rétroportages officiels : l’équipe de sécurité PHP a fourni des correctifs « rétroportés » (source backports) pour PHP 7.4, 8.0 et 8.1, destinés à ceux qui compilent PHP eux-mêmes ou qui n’ont pas accès à un paquet fourni par un fournisseur ;
  • Correctifs tiers : des sociétés spécialisées comme TuxCare proposent des versions corrigées pour des branches encore plus anciennes (jusqu’à PHP 5.2), pour les organisations qui ne peuvent pas migrer immédiatement ;
  • Les distributions Linux et hébergeurs ont rétroporté les correctifs dans leurs propres paquets : vérifiez auprès de votre distribution ou de votre hébergeur si une mise à jour de sécurité est disponible pour votre version de PHP 7.

Attention toutefois : ces correctifs pour PHP 7 sont des solutions d’appoint. Ces branches ne recevront plus de correctifs à l’avenir (la faille suivante ne sera probablement pas couverte), et PHP 8.2 elle-même cessera d’être corrigée après le 31 décembre 2026. La vraie solution durable reste de planifier une migration vers une version maintenue de PHP (8.3 ou plus récent) — ce qui implique généralement aussi une montée en version de Dolibarr.

Les hébergeurs, les éditeurs de systèmes d’exploitation et les fournisseurs de solutions ont reçu les correctifs en avance et les ont déployés dans les heures ou jours suivants. Pour un serveur correctement mis à jour, le risque est aujourd’hui écarté.

Ce que cela signifie pour votre ERP Dolibarr

Dolibarr est un logiciel de gestion d’entreprise (facturation, comptabilité, stocks, CRM…) qui fonctionne avec PHP : il est donc directement concerné par cette faille. Voici les points essentiels :

1. La faille ne vient pas de Dolibarr C’est le « moteur » PHP, sur lequel Dolibarr repose, qui était vulnérable. Dolibarr lui-même n’a pas eu de défaut de sécurité à corriger dans cet épisode.

2. Ce qui compte, c’est la version de PHP installée sur le serveur qui héberge votre Dolibarr. Si le serveur a été mis à jour vers l’une des versions corrigées ci-dessus, votre ERP est protégé.

3. Si votre Dolibarr est hébergé chez un prestataire (hébergeur spécialisé ou DSI externe), la mise à jour de PHP a très probablement été faite par leurs soins dans la foulée. Une simple question à leur poser suffit : « Notre Dolibarr tourne-t-il sur une version de PHP corrigée (8.2.35 minimum) ? »

4. Si votre Dolibarr est en Docker, il faut vérifier que l’image du conteneur a été reconstruite avec un PHP corrigé — c’est une opération à la charge de celui qui maintient l’installation.

5. Si Dolibarr tourne sur votre propre serveur avec un PHP ancien (7.4 à 8.1), des correctifs rétroportés ont été publiés (voir la section « Et pour les versions plus anciennes »), mais la solution durable reste une migration vers une version maintenue de PHP.

Les risques si rien n’est fait sont loin d’être théoriques pour une entreprise : un attaquant qui exploite la faille peut voler vos données clients et fournisseurs, vos factures, vos données bancaires, chiffrer vos fichiers pour demander une rançon, ou utiliser votre serveur pour attaquer d’autres cibles.

Les bons réflexes à conserver

Cet épisode est une excellente leçon de « cybersécurité pour tous » :

  • Tenez vos logiciels à jour : la grande majorité des attaques exploitent des failles déjà corrigées. Appliquer les mises à jour, c’est se verrouiller la porte.
  • Vérifiez la version de PHP de vos outils web au moins une fois par an, et exigez une version encore maintenue.
  • Sauvegardez régulièrement** vos données (factures, base Dolibarr) sur un support distinct : c’est la meilleure assurance contre les rançonnels.
  • Limitez l’accès à votre Dolibarr depuis l’extérieur quand c’est possible, et utilisez des mots de passe solides.
  • En cas de doute, débranchez : comme les préfectures l’ont fait, mettre temporairement hors ligne un service non corrigé est toujours préférable à le laisser exposé.

En résumé

Le 21 octobre 2026, deux failles critiques découvertes grâce à l’IA ont menacé la « colonne vertébrale du web » — PHP. Grâce à une coordination exceptionnelle, les correctifs ont été publiés en moins de 24 heures et massivement appliqués. Dolibarr, comme tout logiciel fonctionnant sur PHP, était exposé à travers son serveur ; un serveur mis à jour vers PHP 8.2.35 ou plus récent est aujourd’hui protégé. La vigilance reste de mise : ces failles sont activement exploitées, et les serveurs oubliés restent des proies faciles.

Sources principales

  • Anssi / CERT-FR : alerte du 21 octobre 2026 sur les vulnérabilités critiques PHP
  • Fondation PHP : avis de sécurité du 20 et 21 octobre 2026 (CVE-2026-109618, CVE-2026-109619)
  • CISA (États-Unis) : alerte de mise à jour immédiate, inscription au catalogue KEV le 26 octobre 2026
  • CERT-EU : avis 2026-018 « Critical Vulnerabilities in PHP »
  • Forum Dolibarr France : fil « Correctif de sécurité PHP pour les failles CVE-2026-109618 et CVE-2026-109619 »
  • Dépêches AFP des 21, 22 et 24 octobre 2026 ; analyses Wiz, watchTowr, Rapid7, Unit 42, IT-Connect, Cybelangel

Conseils Tiaris :

  • Nos serveurs utilisent tous des versions corrigées de PHP. Les utilisateurs de notre solution e-Tiaris ne sont donc plus exposés.
  • Nous recommandons de migrer Dolibar vers une version récente (23 ou plus) et d’utiliser une version de PHP non obsolète c’est à dire bénficiant de correctifs par la communauté (8.3 ou plus). Nous suivons une procédure sûre et fiable pour les migrations de Dolibarr., afin de ne pas perdre de données Contactez-nous pour toute information.
Revenir en haut