En octobre 2026, deux failles critiques de PHP ont rappelé pourquoi un site qui fonctionne doit aussi être maintenu. Elles peuvent permettre à un attaquant d’exécuter du code à distance sans se connecter à un compte. Vérifier l’environnement, appliquer les correctifs et contrôler les fonctions utiles du site devient alors une intervention prioritaire.
Ce deuxième volet des Étapes essentielles de la maintenance d’un site web prolonge le premier, Pourquoi maintenir son site ?. Il revient sur l’alerte PHP d’octobre 2026 pour expliquer ce qu’il faut vérifier avec votre hébergeur et votre prestataire. L’objectif : protéger les données et garder les fonctions utiles de l’entreprise opérationnelles.
PHP : une couche du site que l’on ne voit pas
PHP est un langage exécuté sur le serveur. Il fait notamment fonctionner WordPress et de nombreuses applications web : traitement d’un formulaire, accès à une base de données, espace client ou génération d’un document. Le navigateur reçoit le résultat de ce traitement.
La maintenance concerne donc plusieurs couches : le serveur, PHP, l’application, ses extensions et son code spécifique. Mettre à jour WordPress ne prouve pas que PHP a été mis à jour ; changer PHP ne corrige pas automatiquement une extension vulnérable.
Tous les sites n’utilisent pas PHP. Un site statique peut servir directement des pages HTML, tout en dépendant d’un formulaire externe ou d’autres services. Il faut inventorier les composants réellement utilisés avant de décider quoi corriger.
Que signifie « une faille PHP » ?
L’expression peut désigner une vulnérabilité du moteur PHP lui-même ou, par raccourci, un défaut dans une application écrite en PHP. Les conséquences et les corrections diffèrent. Un contrôle d’accès manquant dans une extension nécessite une correction de cette extension ; une vulnérabilité du moteur peut demander une intervention sur l’environnement d’hébergement.
Selon le défaut et la configuration, un attaquant peut accéder à des informations, modifier des contenus ou exécuter du code sur le serveur. La simple présence de PHP ne suffit pas à conclure qu’un site est exposé à une faille précise. Il faut rapprocher l’avis de sécurité de la version installée et des conditions d’exploitation.
Le manuel de sécurité PHP distingue notamment les questions d’installation, de fichiers, de sessions et de base de données. Cette diversité explique pourquoi un unique bouton « mettre à jour » ne couvre pas toute la sécurité du site.
Octobre 2026 : deux failles critiques dans PHP
Le 21 octobre 2026, le projet PHP a publié des correctifs pour CVE-2026-109618 et CVE-2026-109619, deux vulnérabilités pouvant permettre une exécution de code à distance sans authentification. Elles touchent la gestion de la mémoire et de l’état interne des requêtes. L’annonce officielle de PHP précise que les installations servant des requêtes web sont concernées, avec un risque jugé particulièrement élevé pour Apache utilisant le module mod_php.
L’exemple technique est parlant : PHP décrit une démonstration où une requête sans authentification peut déclencher l’attaque avant même l’exécution du code de l’application. Mettre à jour uniquement le CMS — l’outil de gestion du contenu, comme WordPress — ou ses extensions ne suffit donc pas à corriger ces défauts du moteur PHP.
Le CERT-FR, dans son alerte du 21 octobre mise à jour le 27 octobre 2026, signale des tentatives d’exploitation ciblant des déploiements spécifiques. Il recommande d’isoler les équipements affectés puis de migrer vers une version maintenue avec les correctifs. La faisabilité d’une attaque dépend de l’environnement ; une tentative observée ne prouve pas à elle seule qu’un système a été compromis.
Un exemple concret : le site du NCSC néerlandais temporairement hors ligne
Le NCSC-NL, centre national néerlandais de cybersécurité, indique avoir temporairement retiré son propre site du réseau par précaution. D’autres organismes, dont des administrations, ont également désactivé leurs sites. Son point du 23 octobre précise que l’exploitation est complexe, tout en maintenant la recommandation d’installer rapidement les correctifs.
Il s’agit d’une interruption préventive documentée, pas d’un piratage confirmé de ces sites. Pour une entreprise, le cas illustre un coût concret : devoir suspendre un service pendant la sécurisation. Un inventaire à jour, un responsable joignable et une procédure d’intervention préparée facilitent la décision et la remise en service.
Quels correctifs vérifier avec son hébergeur ?
Les premières versions corrigeant ces deux vulnérabilités sont PHP 8.2.35, 8.3.36, 8.4.27 et 8.5.12. Ces numéros sont des repères pour l’alerte d’octobre : demandez à votre hébergeur une version maintenue intégrant les correctifs et les mises à jour ultérieures, ou la confirmation des correctifs fournis par sa distribution.
Le suivi doit aussi tenir compte des avis suivants. Le 23 octobre, PHP a signalé CVE-2026-115560, un autre risque d’exécution de code dans une combinaison inhabituelle de configuration et de code applicatif. L’avis complémentaire de PHP précise les conditions et la mesure provisoire concernant le suivi de progression des envois de fichiers. Le prestataire doit vérifier leur applicabilité à votre installation.
Sources vérifiées le 1er novembre 2026. Une intervention doit s’appuyer sur les derniers avis de l’éditeur et de l’hébergeur disponibles au moment de sa réalisation.
Notre intervention lors de l’alerte d’octobre 2026
Lors de cette alerte, l’équipe WebOptimizer a placé les services concernés en maintenance et appliqué le correctif le jour même sur les serveurs qu’elle gère. La maintenance a donc pris la forme d’une intervention immédiate sur l’environnement d’hébergement, au-delà des mises à jour du contenu du site.
Ce retour d’expérience rappelle l’intérêt d’avoir une équipe responsable du suivi technique et en mesure d’intervenir lorsqu’un correctif urgent devient disponible. La continuité d’un service se prépare aussi pendant les périodes où tout semble fonctionner.
Vérifier si votre environnement est encore suivi
Demandez à votre hébergeur ou à votre prestataire la version exacte de PHP utilisée par le site, son mode d’exécution et la politique de mise à jour. Une indication comme « PHP 8 » manque de précision. La version utilisée pour les pages web peut aussi différer de celle des tâches planifiées.
Consultez ensuite le calendrier officiel des versions prises en charge. Il distingue le support actif, les correctifs de sécurité et la fin de prise en charge. Une branche maintenue doit aussi recevoir ses mises à jour correctives. Certains hébergeurs fournissent des correctifs rétroportés : des corrections adaptées à une version plus ancienne du logiciel. Si c’est le cas du vôtre, demandez-lui de confirmer que l’avis de sécurité concerné est bien couvert.
Une branche arrivée en fin de support appelle un projet de migration. L’absence de panne visible ne justifie pas de la conserver indéfiniment. Si une ancienne extension empêche le changement, il faut prévoir sa mise à niveau, son remplacement ou sa suppression.
Corriger sans perdre les fonctions utiles
Pour une PME, la bonne question est aussi : après l’intervention, les demandes arrivent-elles encore et les commandes sont-elles correctement enregistrées ? Préparez une intervention vérifiable avec les personnes responsables.
- Qualifier l’urgence. Identifier le composant, l’avis de sécurité et les conditions d’exposition. Une vulnérabilité exploitable sur un service public peut nécessiter une intervention hors du calendrier habituel.
- Préparer la reprise. Sauvegarder les fichiers, la base et la configuration nécessaires, avec une copie séparée et une restauration vérifiée. Définir comment préserver les données reçues pendant l’intervention.
- Vérifier la compatibilité. Tester le changement sur une préproduction, c’est-à-dire une copie de test du site séparée du service public. Elle doit représenter l’environnement utilisé : application, extensions, bibliothèques et code spécifique. Une montée de branche PHP peut révéler des incompatibilités.
- Appliquer et confirmer. Mettre à jour les composants concernés, puis vérifier la version effectivement utilisée par les services, y compris les traitements planifiés.
- Tester les parcours métier. Contrôler la connexion, le formulaire, les envois de courriels et les échanges avec les outils de l’entreprise. Utiliser des données de test identifiées et un environnement adapté pour les paiements.
- Consigner et surveiller. Garder la date, les versions, le responsable et les résultats des contrôles ; suivre ensuite les erreurs et les demandes en attente.
Un retour arrière mérite la même préparation : rétablir une version vulnérable peut réouvrir l’exposition, et restaurer une ancienne base peut effacer des opérations récentes. En cas d’incompatibilité, une restriction temporaire du service peut être préférable, selon l’impact et l’avis de l’équipe technique.
Et si le site a déjà été compromis ?
Un correctif ferme une vulnérabilité ; il ne supprime pas nécessairement les fichiers ajoutés, les comptes créés ou les accès dérobés auparavant. Si vous observez des modifications inexpliquées, des redirections ou des comptes inconnus, traitez aussi l’hypothèse d’un incident.
Faites préserver les journaux et les éléments utiles au diagnostic, limiter l’exposition, rechercher le point d’entrée et préparer une restauration depuis un état fiable. Les accès potentiellement compromis doivent être renouvelés dans le cadre de cette reprise. Le dossier sur une compromission WordPress complète ce sujet.
Réduire aussi ce qui reste exposé
Appliquer les correctifs fait partie de l’entretien. Le choix de l’architecture permet aussi de réduire le nombre de composants accessibles depuis Internet : conserver les fonctions nécessaires, retirer les modules inutilisés et limiter l’accès aux interfaces d’administration.
Pour un site vitrine ou un carnet d’articles, des pages préparées à l’avance peuvent suffire. Un générateur de site statique comme Hugo produit notamment des fichiers HTML : leur consultation peut se faire sans exécuter PHP ni interroger une base de données sur le serveur public. Si ces composants sont absents de l’environnement qui sert le site, leurs vulnérabilités ne constituent plus des points d’entrée sur cet environnement.
Les fonctions interactives restent à examiner : un formulaire, une réservation ou un espace client peut dépendre d’un autre service qui nécessite son propre suivi. L’hébergement, les accès de publication et les outils de génération doivent également être entretenus. Le choix dépend donc des fonctions utiles à l’entreprise et des moyens disponibles pour les maintenir.
Dans un prochain article : « Un site moins exposé : quand choisir une architecture statique ? » Nous verrons quels besoins elle couvre, comment conserver les fonctions indispensables et quelles tâches de maintenance restent nécessaires.
Les questions à transmettre à votre prestataire
- Quelle version de PHP sert le site et les tâches planifiées ?
- Qui suit les avis de sécurité et qui applique les correctifs ?
- Notre environnement est-il concerné par l’avis identifié ?
- Quelle sauvegarde peut être restaurée, et quand sa restauration a-t-elle été vérifiée ?
- Quels parcours seront testés après intervention, par qui ?
- Que prévoit-on si une extension bloque la migration ?
La maintenance devient concrète lorsque chaque réponse mène à un responsable et à une vérification. Notre guide pour surveiller les applications web et leurs API aide à prolonger ces contrôles après la mise à jour.
Pour décrire un besoin de maintenance, indiquez l’application utilisée, le message de l’hébergeur et les fonctions indispensables à votre activité. Ne transmettez ni mot de passe ni clé d’accès dans cette première demande.