Le 21 octobre 2026, le projet PHP a publié en urgence quatre versions correctives pour combler deux failles critiques. Six jours plus tard, Capcom coupait les serveurs de Street Fighter V et retirait le jeu de la vente sur Steam et le PlayStation Store. Entre les deux, des milliers de sites web ont dû être mis à jour à la hâte. Pour une entreprise qui possède un site vitrine, une boutique en ligne ou un intranet, cette séquence est un rappel très concret : la version de PHP qui fait tourner votre site n’est pas un détail technique réservé au prestataire.
Ce qui s’est passé en octobre
Les deux vulnérabilités, référencées CVE-2026-109618 et CVE-2026-109619, touchent des zones de PHP que presque chaque requête traverse : la gestion de la mémoire et celle des erreurs. Selon la PHP Foundation, elles permettent, dans certaines conditions, à un attaquant non authentifié d’exécuter du code sur le serveur. Leur score de gravité est de 9,2 sur 10. Sur une configuration Apache avec mod_php, une seule requête suffisait à déclencher l’attaque avant même que le code du site ne s’exécute.
Les versions corrigées sont PHP 8.5.12, 8.4.27, 8.3.36 et 8.2.35. Le CERT-EU, l’équipe de réponse aux incidents des institutions européennes, a recommandé de les installer « dès que possible », en signalant que des preuves de concept circulaient déjà. Fait rare, l’équipe de sécurité de PHP a aussi publié des correctifs minimaux pour des branches qu’elle ne maintient plus (7.4, 8.0 et 8.1), signe que le parc concerné est immense. L’éditeur de la plateforme d’hébergement Laravel Forge précise d’ailleurs que les failles remontent à des versions de PHP datant de 2004.
Street Fighter V, l’exemple qui parle à tout le monde
Le cas Capcom montre ce qui arrive quand une application ancienne repose sur une brique logicielle qu’on ne peut pas mettre à jour en un après-midi. Les fonctions en ligne de Street Fighter V, sorti en 2016, utilisent PHP. L’éditeur japonais a d’abord lancé une maintenance d’urgence, puis, faute de correctif rapide, a fermé les combats en ligne et suspendu les ventes. Les joueurs gardent le mode hors ligne, mais ne peuvent plus affronter personne sur Internet, et aucune date de retour n’a été annoncée. Le récit de l’affaire Street Fighter V publié par Gameulous résume bien l’enjeu : ce qui est coupé, c’est le cœur du jeu.
Remplacez « jeu de combat » par « boutique en ligne » ou « espace client », et le scénario devient celui d’une PME : un site construit il y a plusieurs années, jamais vraiment modernisé, et qu’on ne sait plus mettre à jour sans risque de tout casser. Ce jour-là, le choix se résume souvent à rester exposé ou à fermer le service.
Votre site est-il concerné ? Les chiffres de WordPress
WordPress, qui fait tourner une large part des sites d’entreprise, publie les versions de PHP utilisées par les installations qui contactent ses serveurs. Début novembre 2026, ces statistiques montrent qu’environ 32 % des sites WordPress tournent encore sur PHP 8.1 ou une version plus ancienne, toutes en fin de vie. La seule branche 7.4, abandonnée depuis fin 2022, pèse encore plus de 14 %.
Et le calendrier va aggraver la situation. D’après le tableau officiel de php.net :
- PHP 8.2 ne recevra plus aucun correctif de sécurité après le 31 décembre 2026, soit dans moins de deux mois. Elle équipe pourtant près de 23 % des sites WordPress ;
- PHP 8.3 est maintenue pour la sécurité jusqu’au 31 décembre 2027 ;
- PHP 8.4 jusqu’au 31 décembre 2028 ;
- PHP 8.5, la plus récente, jusqu’au 31 décembre 2029.
Autrement dit, au 1er janvier 2027, plus de la moitié des sites WordPress fonctionneront sur une version de PHP qui ne reçoit plus de correctifs officiels. Lors de la prochaine faille de ce type, ils n’auront pas de mise à jour simple à installer.
Comment vérifier la version de PHP de son site
Pas besoin d’être développeur pour savoir où l’on en est. Trois méthodes suffisent dans la plupart des cas :
- Dans WordPress : le menu Outils, puis Santé du site, onglet Infos, rubrique Serveur, affiche la version de PHP. WordPress signale aussi lui-même une version obsolète dans l’onglet État ;
- Dans l’espace client de l’hébergeur : la plupart des offres mutualisées (OVHcloud, o2switch, Hostinger, Infomaniak…) affichent et permettent de changer la version de PHP depuis le tableau de bord ;
- Auprès de votre prestataire : si un contrat de maintenance existe, demandez par écrit la version installée, la date du dernier correctif appliqué et la version cible prévue.
Attention à un piège : sur certains serveurs Linux, les correctifs de sécurité sont rétroportés par la distribution, et la commande php -v affiche alors le même numéro avant et après la mise à jour. Seul l’administrateur du serveur peut confirmer que le paquet corrigé est bien installé.
Mettre à jour sans casser son site
La crainte qui bloque la plupart des propriétaires de sites, c’est la page blanche ou l’erreur 500 après le changement de version. Elle est fondée : un thème ou une extension abandonnée peut ne pas supporter PHP 8.3 ou 8.4. La bonne méthode tient en quelques étapes.
- Sauvegarder les fichiers et la base de données, et vérifier que la sauvegarde se restaure ;
- Tester sur une copie du site (environnement de préproduction) avec la nouvelle version de PHP avant de toucher au site en ligne ;
- Mettre à jour d’abord le CMS, le thème et les extensions, puis seulement PHP ;
- Remplacer les extensions qui ne sont plus maintenues plutôt que de bloquer tout le site sur une vieille version pour elles ;
- Surveiller les journaux d’erreurs dans les jours qui suivent la bascule.
Pour un site vitrine standard, l’opération prend quelques heures. Pour un développement sur mesure ancien, elle peut demander une vraie refonte de certaines parties du code. C’est précisément ce qu’a vécu Capcom avec un jeu de dix ans : plus on attend, plus l’écart à rattraper est grand.
La maintenance, une assurance plus qu’une dépense
L’épisode d’octobre a une leçon simple : un site web n’est jamais « terminé ». Les mises à jour de PHP, du CMS et des extensions font partie de son coût de possession, au même titre que l’hébergement ou le nom de domaine. Les entreprises qui avaient un contrat de maintenance actif ont été corrigées en quelques heures, souvent sans même s’en apercevoir. Les autres ont découvert le problème dans la presse, ou par un message de leur hébergeur.
Avant la fin de l’année, une vérification s’impose donc : si votre site tourne sur PHP 8.2 ou une version antérieure, planifiez dès maintenant la migration vers PHP 8.4 ou 8.5. Mieux vaut le faire à froid, en décembre, qu’en urgence lors de la prochaine alerte.
