Mercredi 21 octobre 2026, les sites internet des préfectures françaises, dont celui de la préfecture de police, sont devenus inaccessibles. Le ministère de l’Intérieur les avait mis hors ligne à titre préventif, à la demande de l’ANSSI. Des universités suisses, des agences publiques aux Pays-Bas ou en Finlande ont fait de même, parfois avant même que le correctif existe.
La cause : deux failles de sécurité critiques dans PHP, le langage qui fait tourner une très grande partie du web, de WordPress à Magento en passant par une multitude d’applications faites sur mesure. Ces failles touchent le code du langage lui-même, pas seulement vos outils.
Pour un dirigeant de PME ou un responsable informatique, la vraie question n’est pas « comment PHP en est arrivé là ». C’est : chez nous aussi, quelque chose tourne-t-il sur une version vulnérable, et le sait-on seulement ? Cet article part de cet épisode pour répondre à cette question et pour expliquer pourquoi les mises à jour ne peuvent plus être traitées « quand on aura le temps ».
Ce qui s’est passé le 21 octobre 2026, en bref
Deux vulnérabilités, référencées CVE-2026-109618 et CVE-2026-109619, ont été annoncées par l’équipe de sécurité (security team) de PHP. Toutes deux sont notées 9,2 sur 10 selon l’échelle CVSS v4.0, soit le niveau « critique ». Elles peuvent permettre à un attaquant d’exécuter du code à distance sur un serveur sans être authentifié : prendre la main sur la machine, modifier le site, voler des données. C’est la même famille de risques que l’injection SQL ou l’injection de commandes.
Le calendrier explique en partie la panique. Le correctif de ces failles était prévu le mercredi 21 octobre à 16 h, heure de Paris, et l’équipe PHP avait prévenu la veille. Selon la presse, des détails ont fuité avant la publication, ce qui a déclenché une course à la mise hors ligne : certains ont préféré couper leurs sites plutôt que d’attendre un patch qui n’existait pas encore.
Les versions corrigées sont PHP 8.5.12, 8.4.27, 8.3.36 et 8.2.35. Les versions 8.1 et antérieures ne reçoivent plus de mises à jour du projet PHP, même si certains distributeurs Linux ou fournisseurs de support à long terme proposent des correctifs rétroportés.
Point à retenir : l’avis officiel (security advisory) précise que seule la mise à jour est une solution complète. Les réglages de contournement, qui modifient la configuration, réduisent l’exposition à certains scénarios sans rendre l’installation sûre.
Mon système informatique est-il vulnérable ? Les cinq endroits où regarder
« Nous n’utilisons pas PHP » est la réponse la plus fréquente, et la moins fiable. PHP se cache souvent là où personne ne l’a installé volontairement.
1. Votre site internet et vos outils web
Tout site construit avec WordPress, Drupal, Joomla ou Magento repose sur PHP, tout comme de nombreux modules de boutique en ligne, de prise de rendez-vous ou de formulaires qui collectent les données de vos utilisateurs. Première question : qui héberge ce site, et qui gère le serveur ? La réponse détermine qui doit appliquer le correctif.
2. Les serveurs : la version de PHP réellement installée
Savoir qu’on « utilise PHP 8.3 » ne suffit pas, il faut connaître la version de correctif (8.3.36 ou non). Attention à une source d’erreurs fréquente : sur beaucoup de distributions Linux, le numéro affiché reste ancien alors que le correctif de sécurité a été appliqué par rétroportage. À l’inverse, un numéro « récent » ne garantit rien s’il n’est pas à jour. La source fiable est l’avis de votre distributeur ou de votre hébergeur, pas un coup d’œil au numéro.
3. Vos prestataires et hébergeurs
Sur un hébergement mutualisé ou géré, c’est votre prestataire qui applique le correctif. Posez-lui la question par écrit, en demandant ces informations : version en production, date d’application, mesures prises en attendant. Une réponse claire en quelques heures est un bon signe. À défaut de réponse, c’est un signal d’alerte.
4. Les environnements oubliés
L’ancien site de campagne, la version de test jamais supprimée, l’extranet d’un projet terminé : ces systèmes, que plus aucun utilisateur n’utilise, ne sont plus mis à jour mais restent joignables depuis internet. Ce sont des cibles de choix pour les attaques : ils cumulent les vulnérabilités, précisément parce que personne ne les surveille, et abritent parfois des données sensibles oubliées.
5. Les applications métier qui ont une couche web
Votre ERP ou votre CRM n’est pas forcément concerné par PHP. En revanche, ce qui l’entoure peut l’être : portail client, extranet fournisseurs ouvert aux utilisateurs externes, passerelle d’échange, site marchand connecté à la gestion commerciale, autant de briques exposées aux injections et à la fuite de données. Quand une application métier est exposée sur internet, chaque brique qui la sert entre dans votre périmètre de risque. À aborder avec votre intégrateur, surtout si les accès distants ont été montés au fil des années sans cartographie d’ensemble.
Faille détectée : que faire dans les 72 premières heures
Face à une vulnérabilité critique, l’ordre des actions compte plus que leur nombre.
- Dresser la liste de ce qui est exposé à internet : sites, portails, API, serveurs de test. Sans inventaire des systèmes et des données, impossible de prioriser.
- Identifier la version en production de chaque composant auprès de l’hébergeur ou de l’équipe technique, avec une réponse écrite.
- Appliquer la mise à jour de sécurité en priorité sur les systèmes exposés, après une sauvegarde des données vérifiée et, si possible, un passage rapide en environnement de test.
- Si la mise à jour est impossible tout de suite, appliquer les mesures de contournement de l’éditeur sans les confondre avec une protection complète, et réduire l’exposition : restriction d’accès, filtrage, voire mise hors ligne temporaire des services non essentiels.
- Surveiller les journaux (requêtes inhabituelles, processus inattendus, fichiers modifiés) et conserver une trace de ce qui a été fait.
- Prévoir la suite pour les versions non supportées : montée de version ou support étendu, mais pas statu quo.
Pourquoi les mises à jour ne peuvent plus attendre
Dès qu’un correctif est public, il renseigne aussi ceux qui cherchent à attaquer : comparer la version corrigée à l’ancienne montre où se situait la faille. Les attaquants s’appuient désormais sur des outils d’analyse automatisée, et l’IA accélère encore cette comparaison, comme le balayage des systèmes exposés. Plus on tarde, plus la fenêtre de vulnérabilité est longue.
Deux autres éléments rendent l’attente risquée.
- Les failles sans authentification n’ont pas besoin de complice. Quand l’attaque ne requiert aucun identifiant, sensibiliser l’utilisateur ou renforcer les mots de passe ne suffit plus : le meilleur des mots de passe n’arrête pas un attaquant qui n’en a pas besoin. Seul le système à jour protège.
- Le support a une date de fin. PHP 8.2 cessera de recevoir des correctifs de sécurité le 31 décembre 2026, et les versions 8.1 et antérieures sont déjà hors support. Un système qui fonctionne bien mais n’est plus maintenu est un risque qui grandit chaque mois, d’autant que l’IA facilite la recherche de cibles obsolètes.
Ce que les mises à jour coûtent vraiment
« Il suffit de mettre à jour » est facile à écrire, plus délicat à appliquer. Voici pourquoi les entreprises repoussent, et ce qui change la donne.
- La peur de casser quelque chose. Une application au code sur mesure peut dépendre de fonctionnalités qui changent d’une version à l’autre. Sans environnement de test, chaque mise à jour est un pari, et les erreurs coûtent cher.
- L’absence de responsable clair. Entre la direction, le prestataire web, l’hébergeur et l’informatique interne, personne ne sait qui doit déclencher la mise à jour.
- La dette technique. Un système jamais mis à jour demande un rattrapage bien supérieur à un suivi régulier.
- L’interruption de service. Redémarrer un serveur ou basculer une version a un coût.
Ces freins sont réels. La réponse n’est pas d’ignorer la mise à jour mais de la rendre moins risquée : sauvegardes testées, environnement de recette, maintenance planifiée, plan de retour en arrière.
Mettre en place une gestion des correctifs durable
Les organisations qui ont répondu vite avaient un point commun : elles savaient ce qu’elles avaient. Voici l’ossature d’une gestion des correctifs (patch management) adaptée à une PME.
| Étape | Question à se poser | Ce qui change concrètement |
|---|---|---|
| Inventaire | Que possédons-nous, où, et qui l’héberge ? | Une liste à jour des serveurs, sites, applications, données hébergées et versions |
| Responsabilités | Qui décide, qui exécute, qui contrôle ? | Un nom par système, y compris chez les prestataires |
| Veille | Comment être alerté des failles ? | Abonnement aux avis du CERT-FR, analyse des alertes des éditeurs et de l’hébergeur |
| Priorisation | Quel système est exposé à internet ? | Les services exposés et critiques passent avant le reste |
| Test et retour arrière | Peut-on revenir en arrière ? | Sauvegarde vérifiée, environnement de recette, procédure écrite |
| Suivi | Le correctif est-il vraiment appliqué ? | Contrôle de version après intervention, trace conservée |
Deux conseils de bon sens. D’abord, séparer les mises à jour d’urgence (faille critique : en quelques heures ou jours) des mises à jour planifiées (mensuelles ou trimestrielles). Ensuite, ne pas confondre mise à jour de sécurité et montée de version majeure : la première doit être rapide, la seconde se prépare.
Et mon ERP, mon CRM, mes applications de gestion ?
C’est la question de beaucoup de dirigeants utilisant Sage ou Divalto. La réponse honnête : cela dépend de l’architecture, pas du logiciel. Un ERP installé sur un serveur interne, non exposé à internet, n’est pas concerné par une faille PHP. Un ERP hébergé, avec des accès distants, un portail web ou des connecteurs vers une boutique en ligne, mérite une vérification de toute la chaîne : système d’exploitation, serveur web, passerelles, accès VPN.
La sécurité d’un système de gestion se juge sur son environnement : le serveur, les accès, les sauvegardes, le suivi des mises à jour. C’est un des points abordés dans notre contenu sur l’hébergement de Sage 100, et l’un des sujets qu’un intégrateur Sage 100 doit traiter avec vous au-delà de la seule configuration du logiciel.
FAQ : Faille de sécurité
Ma société est-elle concernée par la faille PHP du 21 octobre 2026 ?
Si vous avez un site WordPress, Drupal, Joomla, Magento, une boutique en ligne ou une application web en PHP, oui, potentiellement. Les versions corrigées sont PHP 8.5.12, 8.4.27, 8.3.36 et 8.2.35. Les versions 8.1 et antérieures ne sont plus maintenues par le projet PHP : renseignez-vous auprès de votre distributeur ou migrez.
Faut-il mettre hors ligne son site en cas de faille critique ?
Cela dépend de la sensibilité du service et de la disponibilité du correctif. Pour un service exposé qui manipule des données sensibles et dont le patch tarde, une mise hors ligne temporaire peut se justifier. Pour la plupart des sites, la priorité est d’appliquer rapidement la mise à jour et de surveiller.
Qui est responsable des mises à jour : moi, mon hébergeur ou mon prestataire ?
Cela se lit dans vos contrats : périmètre, délais, informations en cas d’incident. Un hébergeur géré prend en charge la couche serveur, un prestataire web les applications dont il a la charge. À défaut de répartition écrite, personne ne se sent responsable : clarifier ce point est souvent le premier gain de sécurité.
Un ERP comme Sage ou Divalto est-il exposé à ce type de faille ?
Pas nécessairement. Un ERP interne, que l’utilisateur n’atteint pas depuis internet, est peu concerné, alors qu’un environnement avec accès distants, portail web ou connecteurs doit être vérifié dans sa globalité.
Conclusion : les prochaines failles de sécurité arrivent, où en serez-vous ?
L’épisode du 21 octobre n’est ni le premier ni le dernier. Il révèle l’écart entre les organisations qui savent ce qu’elles exploitent et celles qui le découvrent le jour de l’alerte. Faire l’inventaire, nommer des responsables, fixer des délais pour les correctifs critiques : ce sont des chantiers modestes pour les entreprises, comparés au coût d’un site compromis, de données volées ou d’une base de données exposée. Pour une assistance et prévention en cybersécurité vous pouvez vous rendre sur cybermalveillance.gouv.fr.
Si vous souhaitez faire un point sur votre infrastructure, vos accès distants et le suivi de vos mises à jour, parlons-en. Et si les usages de l’IA vous intéressent sous l’angle de la sécurité, notre article sur le Shadow AI en entreprise prolonge la réflexion sur l’IA et les données.
Vous pourriez également être intéressé par les articles suivants :
- Faille de sécurité : comment savoir si votre système informatique est vulnérable ?
- Shadow AI en entreprise : faut-il interdire l’IA ou apprendre à mieux la maîtriser ?
- Sécurité Microsoft 365 : ce qu’il faut vraiment sécuriser en priorité
- E-reporting 2027 : les changements à venir pour les TPE et PME
- Facturation électronique 2027 : le plan d’action pour TPE et PME après l’échéance de septembre 2026
