Deux failles critiques dans PHP : ce que ça change pour votre site
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. 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 Media 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.
Les deux ensemble ont été surnommées PHP2Shell.
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 rien pour les branches 8.1 et antérieures. Mais 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.
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. Le code vulnérable remonte à PHP 5.4.0. Il a vécu quatorze ans dans le logiciel qui fait tourner environ 70 % du web.
Et l’IA, dans cette histoire, n’est pas la coupable. C’est le chien de garde. La firme Calif a trouvé la première faille en août 2026 avec l’aide d’un modèle d’OpenAI. L’équipe Wiz de Google a trouvé les deux indépendamment quelques semaines plus tard. Personne n’avait rien vu pendant quatorze ans ; des machines l’ont vu en un été.
Ce qui a changé n’est donc pas la sécurité de PHP. C’est la vitesse à laquelle on découvre ce qui était déjà cassé. OpenAI s’attend à ce que des découvertes semblables augmentent fortement dans les prochains mois.
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.
