Faille critique de PHP : mettre à jour, puis penser statique

Le 21 octobre 2026, l’équipe de PHP a publié une mise à jour de sécurité qui corrige deux failles critiques. Sur les réseaux, on a lu que « 80 % d’internet » était menacé et que les attaquants auraient tout compris « en 15 minutes ». La réalité est un peu moins spectaculaire, mais elle reste sérieuse. Voici ce qui est vrai, ce qu’il faut faire aujourd’hui, et la question que cette alerte pose à tous ceux qui ont un site WordPress ou PrestaShop.

Ce qui a été corrigé

Les deux failles portent les numéros CVE-2026-109618 et CVE-2026-109619. L’équipe de PHP les note 9,2 sur 10 dans son annonce sur php.net. Dans les deux cas, un visiteur qui n’est pas connecté peut faire exécuter son propre code par le serveur. La première vient d’une mauvaise gestion de la mémoire quand elle vient à manquer. La seconde vient de données d’une requête qui restent en mémoire et que la requête suivante réutilise.

Toutes les installations qui servent des pages web sont concernées, quel que soit le mode : PHP-FPM, Apache avec mod_php, LiteSpeed, FrankenPHP. Selon php.net, le cas le plus exposé est mod_php, pour lequel une attaque a été démontrée avant même que le code du site ne s’exécute.

Le chiffre de « 80 % d’internet » est arrondi vers le haut. PHP fait tourner la grande majorité des sites dont on connaît la technologie, ce qui inclut presque tous les WordPress, PrestaShop, Drupal et Joomla. La menace est donc large, mais pas universelle.

Ce qu’il faut faire aujourd’hui

Mettez à jour PHP. Les versions corrigées sont 8.5.12, 8.4.27, 8.3.36 et 8.2.35. Si votre hébergeur gère PHP pour vous, vérifiez qu’il l’a fait, ou demandez-le-lui par écrit.

Si votre site tourne encore sur PHP 8.1 ou plus ancien, le projet PHP ne publie plus de version pour ces branches. Son équipe a seulement diffusé des correctifs bruts que votre hébergeur doit appliquer lui-même. C’est le signal qu’une montée de version ne peut plus attendre.

En attendant la mise à jour, php.net propose des réglages qui réduisent le risque, comme désactiver le suivi de progression des envois de fichiers. L’équipe de PHP le dit elle-même : ces réglages ne rendent pas un serveur sûr, seule la mise à jour le fait.

Pourquoi l’IA raccourcit le délai

Une mise à jour de sécurité montre exactement quelles lignes ont changé. Les attaquants comparent l’ancienne et la nouvelle version pour retrouver la faille, puis écrivent une attaque. Ce travail prenait des jours. Avec les assistants de code actuels, il peut prendre quelques heures. Les « 15 minutes » du tweet relèvent de la prédiction, pas d’un fait constaté, mais la tendance est réelle : la fenêtre entre la publication d’un correctif et les premières attaques se resserre.

Pour une entreprise, ça change la règle du jeu. Mettre à jour « dans la semaine » ne suffit plus pour une faille de ce niveau. Il faut mettre à jour dans la journée, et donc avoir quelqu’un qui surveille, teste et déploie, y compris le week-end.

Le vrai avantage d’un site statique

Un site statique est construit une fois, à l’avance. Ce que reçoit le visiteur, ce sont des fichiers déjà prêts : du HTML, des images, un peu de JavaScript. Aucun PHP ne tourne au moment de la visite, et aucune base de données n’est interrogée. Une faille comme celle-ci n’a tout simplement rien à attaquer.

C’est le bénéfice le plus sous-estimé du statique. On en parle surtout pour la vitesse, mais il réduit aussi la dépendance à une technologie précise. Votre site ne dépend plus de la version de PHP, de celle de WordPress, ni des trente extensions qui doivent toutes être à jour en même temps. Il y a moins de pièces, donc moins d’urgences comme celle d’aujourd’hui.

Ce que le statique ne règle pas

Soyons honnêtes : le statique ne supprime pas tout le travail de sécurité.

• Les formulaires ont toujours besoin d’un petit service qui reçoit les envois. Il doit être protégé, mais il est minuscule comparé à un WordPress entier.
• Le back-office existe encore si vous utilisez un outil d’édition comme un CMS headless. Il vit à part, chez un éditeur qui le maintient, et non sur le serveur de votre site public.
• Les API de paiement, de réservation ou de catalogue restent des logiciels à mettre à jour.
• Une boutique en ligne complète, avec panier et comptes clients, ne devient pas statique d’un coup. Les pages produits et le contenu peuvent l’être, le paiement passe par un service spécialisé.

La différence, c’est que la surface exposée devient petite et bien délimitée. Au lieu de surveiller tout un serveur, vous surveillez deux ou trois briques précises.

Le bon moment pour se poser la question

Si cette alerte vous a fait vérifier en urgence votre version de PHP, posez-vous une question simple : votre site a-t-il vraiment besoin d’exécuter du code à chaque visite ? Pour un site vitrine, un blog ou un catalogue, la réponse est presque toujours non.

Commencez par mettre à jour aujourd’hui. Ensuite, si vous voulez sortir de ce cycle d’alertes, notre migration vers un site statique garde toutes vos adresses et votre référencement, et met le site en ligne sur un hébergement qui n’exécute aucun PHP. Pour comprendre ce qui arrive quand la mise à jour arrive trop tard, lisez aussi ce qu’il faut faire quand un site WordPress est piraté.