Ce qui s’est passé le 21 octobre
L’équipe de sécurité de PHP a publié une mise à jour d’urgence pour deux failles critiques, notées 9,2 sur 10 sur l’échelle de gravité CVSS. Les deux permettent à un attaquant de prendre le contrôle d’un serveur sans jamais avoir besoin d’un mot de passe.
Si votre site a été construit avec WordPress, WooCommerce, Drupal, Joomla ou Magento, il fonctionne avec PHP. Autrement dit : ça vous concerne.
Si Blitz héberge votre site, vous n’avez rien à faire. Le correctif a été appliqué sur l’ensemble des sites que nous hébergeons.
Les deux failles, en français
CVE-2026-109618 : PHP gère mal le moment où il manque de mémoire. Dans cette fenêtre, il traite des données à moitié écrites comme si elles étaient valides, ce qui permet d’exécuter du code étranger.
CVE-2026-109619 : après une erreur fatale, PHP garde des références vers de la mémoire déjà libérée. En plus de l’exécution de code, cette faille permet de lire la mémoire du serveur : mots de passe, jetons d’authentification, clés d’API.
Des chercheurs et des firmes de sécurité les ont surnommées PHP2Shell. Ce nom n’est pas officiel, mais c’est celui que vous allez voir passer.
Quelle version faut-il avoir ?
Le projet PHP a publié quatre versions corrigées : 8.5.12, 8.4.27, 8.3.36 et 8.2.35. Si votre site tourne sur l’une de ces branches, la mise à jour suffit, et elle est déjà appliquée chez nous.
Et si vous êtes sur une version plus ancienne ?
Le projet PHP ne publie pas de nouvelle version pour les branches 8.1 et antérieures, seulement des correctifs à appliquer à la main pour 7.4, 8.0 et 8.1. De son côté, cPanel a rétroporté le correctif dans ses propres versions de PHP 8.1, 8.0 et 7.4, dès le 21 octobre. La plupart des hébergements au Québec tournent sur cPanel : il y a donc de bonnes chances qu’une solution existe pour vous.
En dessous de 7.4, il n’y a rien. Ces versions sont abandonnées depuis des années.
Attention : le numéro de version ne prouve rien
C’est le point qui trompe le plus de monde cette semaine. Sur les anciennes branches, le correctif a été ajouté sans changer le numéro affiché. Deux serveurs peuvent afficher exactement la même version de PHP : l’un est corrigé, l’autre pas.
Ne demandez donc pas seulement « quelle version de PHP est-ce que j’utilise ? ». Demandez : « est-ce que le correctif du 21 octobre a été appliqué sur mon serveur ? » Un hébergeur sérieux saura répondre oui ou non, sans détour.
Où on en est, de notre côté
Aucun site que nous hébergeons ne tourne sous PHP 7.4. C’est notre plancher, et tout ce qui s’y trouve est corrigé.
Et ce n’est pas réservé à nos clients sous contrat
C’est important et on y tient : le correctif n’a pas été appliqué seulement aux sites couverts par un plan de maintenance. Il a été appliqué à tous les sites que nous hébergeons, contrat d’entretien ou pas.
À ce niveau de criticité, on ne trie pas la clientèle. Une faille qui permet de prendre le contrôle d’un serveur sans mot de passe ne devient pas moins grave parce qu’un client n’a pas pris l’option. On protège tout le monde, point final.
Mais 7.4 reste un plancher, pas une destination. Depuis des mois, on travaille activement à porter l’ensemble de nos clients vers PHP 8. Ce n’est pas un simple interrupteur : une migration de version majeure demande de reprendre du code, de tester des extensions, parfois de remplacer des composants qui n’ont jamais été prévus pour. On le fait quand même, site par site, parce que c’est la seule direction qui tienne.
Et tout nouveau développement se fait en PHP 8.4. On ne crée plus rien sur une base qu’il faudra migrer dans deux ans. PHP 8.1 n’a plus de soutien depuis la fin de 2025, et PHP 8.2 le perd le 31 décembre 2026.
Si vous avez un système coincé sur PHP 5, ou sur une version inférieure à 7.4, on est capables de le porter. C’est souvent moins lourd qu’on le craint, et c’est toujours moins coûteux qu’une intrusion.
« C’est la faute de l’intelligence artificielle »
Vous allez lire ça cette semaine. C’est faux, et pour une raison qu’il vaut la peine de comprendre.
Le défaut a été écrit par des humains, en 2012. La fonction en cause existe depuis PHP 5.4.0. Il a vécu quatorze ans dans le logiciel qui fait tourner environ 70 % du web.
Dans cette histoire, l’IA a plutôt joué le rôle de chien de garde. Selon Recorded Future, l’équipe de Wiz Research a trouvé la première faille le 19 août 2026, avec Calif et OpenAI, à l’aide d’outils de recherche assistés par l’IA. Personne n’avait rien vu pendant quatorze ans ; des machines l’ont vu en un été.
Ce qui a changé, c’est la vitesse à laquelle on découvre ce qui était déjà cassé.
La conséquence pour vous est très concrète : la vitesse à laquelle vous appliquez les correctifs compte plus aujourd’hui qu’il y a un an. Un site mis à jour deux fois par année n’était pas idéal avant. Il devient un pari.
Quoi faire cette semaine
Demandez à votre hébergeur quelle version de PHP fait tourner votre site, et si elle est corrigée. La réponse devrait prendre deux minutes. Si elle est vague, insistez.
Faites la mise à jour. C’est la seule protection complète.
Et vérifiez que rien n’est déjà entré. C’est la partie dont personne ne parle : mettre à jour protège l’avenir, mais n’annule pas une intrusion déjà survenue. Cherchez :
- un compte administrateur que vous ne reconnaissez pas
- des fichiers modifiés récemment
- une tâche planifiée que personne n’a créée
Et parce que la seconde faille expose la mémoire du serveur, changez les clés d’API qui transitaient par votre site.
Chez nous, c’était fait avant midi
On a été informés de la faille à 8 h le 21 octobre. Les correctifs sont sortis à 14 h UTC, soit 10 h heure du Québec. Nos serveurs étaient corrigés à 100 % dès leur publication.
On ne le dit pas pour se vanter, mais parce que c’est exactement le délai dont on parle plus haut. Entre le moment où une faille devient publique et celui où elle est exploitée, il n’y a plus des semaines : il y a des heures. Un parc de serveurs qu’on surveille se corrige dans la matinée. Un site qu’on met à jour deux fois par année, non.
Vous ne savez pas sur quelle version vous êtes ?
Écrivez-nous, on vérifie avec vous. Ça prend quelques minutes et ça vaut la peine d’être sûr.
Mise à jour du 26 octobre
Deux suites depuis la publication de cet article. Le 23 octobre, le projet PHP a publié un avis sur une autre faille, CVE-2026-115560, liée au téléversement de fichiers dans les sessions. Le 26 octobre, il a publié de nouvelles versions pour Windows (8.5.12-1, 8.4.27-1, 8.3.36-1 et 8.2.35-1) à cause d’une faille dans la bibliothèque Brotli, CVE-2026-111497.
Le conseil ne change pas : gardez PHP à jour et posez la question à votre hébergeur. Les avis du projet PHP sont publics, si vous voulez les lire vous-même.
