Votre site peut afficher « à jour » alors que le logiciel qui le fait fonctionner sur le serveur doit encore être corrigé. Demandez sans attendre à votre hébergeur ou à votre prestataire quelle installation de PHP sert réellement chaque site, et faites-la corriger : le projet PHP appelle à une mise à jour immédiate et indique qu’aucune parade temporaire ne protège complètement.
PHP est le logiciel qui exécute le code de nombreux sites côté serveur. Mettre à jour WordPress, ses extensions ou votre application ne prouve donc pas que PHP a été mis à jour : ce sont des couches différentes, parfois gérées par des entreprises différentes.
Ce que les alertes d’octobre changent
Le projet PHP a annoncé le 21 octobre des correctifs pour deux vulnérabilités critiques permettant une exécution de code à distance sans authentification, c’est-à-dire qu’un inconnu peut faire exécuter ses commandes sur le serveur. Leurs identifiants CVE (références publiques des vulnérabilités) sont CVE-2026-109618 et CVE-2026-109619. Les versions publiées sont 8.5.12, 8.4.27, 8.3.36 et 8.2.35.
L’avis du 23 octobre recommande de désactiver temporairement le suivi de progression des envois de fichiers en session, avec le réglage session.upload_progress.enabled=0, en attendant la prochaine version corrective. Il vise un cas rare lié à la gestion des sessions. Demandez au prestataire de vérifier ce réglage ; s’il l’avait déjà appliqué le 21 octobre, PHP demande de le conserver. Cette précaution complète la mise à jour, elle ne la remplace pas.
Le 26 octobre, PHP a reconstruit ses paquets Windows uniquement. Un paquet est l’ensemble de fichiers d’installation préparé par le projet PHP, l’hébergeur ou un fournisseur du système. Ces paquets Windows portent un suffixe -1, par exemple 8.5.12-1, et corrigent Brotli, une brique logicielle utilisée pour décompresser des données reçues. La version de PHP seule ne distingue donc pas toujours deux installations dont les briques associées diffèrent.
La page des versions supportées par PHP ne classe plus PHP 8.1 parmi les branches suivies. L’avis du 21 octobre précise que PHP 8.1 et les versions antérieures ne reçoivent plus de mises à jour du projet. Certains fournisseurs proposent leurs propres correctifs : demandez une preuve de cette prise en charge ou un passage à une version suivie.
Si la mise à jour ne peut pas être faite immédiatement
Le NCSC demande d’agir immédiatement, en donnant la priorité aux systèmes exposés à Internet. Il renvoie aux mesures temporaires publiées par PHP lorsque la mise à jour est impossible. Celles-ci réduisent certains chemins d’attaque ; elles ne rendent pas une installation sûre.
Le prestataire doit appliquer les mesures pertinentes de l’avis complet. Celui-ci prévoit notamment de désactiver session.upload_progress.enabled dans la configuration du serveur puis de redémarrer tous les processus PHP qui traitent les requêtes. Ce réglage seul n’est pas une protection complète. Si les mesures temporaires ne peuvent pas être appliquées ou prennent trop de temps, le NCSC recommande d’envisager la mise hors ligne jusqu’à protection du système.
Si le système ne peut être ni corrigé ni désactivé immédiatement, le NCSC demande aussi de rechercher des traces de compromission. Faites confier cette vérification à une personne compétente ; une alerte de sécurité ne prouve pas, à elle seule, que votre site a été attaqué.
Le message utile à envoyer au prestataire
Apport Origin : voici une fiche de décision à remplir par site. Elle permet de distinguer une mise à jour annoncée d’une installation réellement vérifiée, sans demander au dirigeant de manipuler le serveur.
- Quel service ? Nom de domaine, application et environnement concerné. Inclure le site public et les outils internes accessibles en ligne.
- Qui intervient ? Hébergeur, agence ou équipe interne, avec une personne responsable du retour.
- Quelle installation ? Version PHP utilisée par ce site et origine du paquet installé. Une réponse portant sur un autre serveur ne clôt pas le sujet. Cette version est-elle encore suivie par PHP ou par un fournisseur qui reprend les correctifs ? Sinon, quel changement de version est prévu ?
- Quelle preuve de correction ? Référence de l’avis du fournisseur et confirmation du paquet déployé. Certaines distributions Linux et certains fournisseurs de support prolongé réintègrent un correctif dans leur propre paquet sans reprendre le numéro de version du projet PHP.
- Quel résultat après intervention ? Vérification du site et de ses fonctions utiles, puis date et personne ayant effectué le contrôle.
Demandez une réponse écrite qui relie ces éléments. « Nous avons lancé les mises à jour » décrit une action ; « ce site utilise ce paquet corrigé et son formulaire fonctionne après intervention » apporte une conclusion vérifiable.
Notre article sur la compromission de LiteLLM et les dépendances d’un logiciel traite d’un autre risque, mais pose la même question d’inventaire : sait-on ce qui est réellement installé ? Pour les applications reliées à des données commerciales, les contrôles d’accès entre un agent IA et une base clients restent un chantier complémentaire, pas un remplacement du correctif PHP.
Exemple fictif : WordPress est à jour, le formulaire ne l’est pas forcément
Une entreprise possède une vitrine WordPress et un ancien formulaire de demande de devis hébergé séparément. L’agence confirme que WordPress est à jour. Cette réponse ne dit rien du PHP du formulaire, qui dépend d’un autre contrat d’hébergement.
La fiche fait apparaître deux lignes et deux responsables. Le premier confirme son paquet corrigé. Le second découvre que l’ancien formulaire utilise PHP 8.1. Il doit vérifier l’existence d’un correctif fourni par son prestataire ou préparer un changement de version, puis traiter l’exposition immédiate selon les mesures décrites plus haut. Le dirigeant voit alors ce qui reste à traiter, au lieu de classer l’ensemble « site à jour ».
Après correction, le contrôle porte sur une demande de devis de test, sa réception et l’affichage de la confirmation. Il ne suffit pas que la page d’accueil s’ouvre. Le prestataire choisit les gestes techniques adaptés et les mesures temporaires éventuelles à partir des avis applicables, puis consigne leur résultat.
À retenir
- Traitez l’alerte immédiatement : les mesures temporaires ne remplacent pas le correctif complet.
- Une mise à jour de WordPress ne prouve pas celle de PHP.
- Une version doit être reliée au paquet du fournisseur et au site réellement servi.
- La décision se ferme avec une preuve de correction et un parcours utile vérifié.
FAQ
Mon hébergeur gère PHP : dois-je intervenir moi-même ?
Demandez-lui de confirmer le périmètre, le correctif et la vérification. L’objectif est d’obtenir une réponse exploitable, pas de changer vous-même une configuration que vous ne maîtrisez pas.
Un ancien numéro de version prouve-t-il que le serveur est vulnérable ?
Pas toujours : un fournisseur peut avoir réintégré le correctif dans son paquet. Demandez la référence de son avis de sécurité et du paquet installé plutôt qu’une comparaison isolée de numéros.
Une correction prouve-t-elle qu’aucun incident n’a eu lieu ?
Non. Corriger le logiciel et rechercher un éventuel incident sont deux vérifications différentes. Si le système n’a pu être corrigé ou désactivé immédiatement, le NCSC demande une recherche de traces de compromission, même avant qu’un incident soit confirmé.
Sources
Sources primaires consultées le 27 octobre 2026 :
- PHP : archive des annonces d’octobre 2026, correctifs du 21 octobre, avis du 23 et paquets Windows du 26.
- PHP : versions supportées.
- NCSC : alerte sur PHP, identification des systèmes et traitement du risque.