Faille critique annoncée : le plan de réaction en 24 heures pour votre site web

Mardi 21 octobre 2026, 14h00 UTC : PHP publie quatre versions corrigeant deux failles critiques exploitables sans authentification. Dans les heures qui suivent, des milliers d'équipes se posent la même question : *quels sont nos sites concernés, et qui s'en occupe ?* Celles qui ont une réponse en dix minutes ont un plan de réaction ; les autres improvisent. Cet article décrit le plan en 24 heures que nous appliquons pour les sites sous maintenance, en prenant la faille PHP comme exemple (les détails techniques sont ici). Il est réutilisable pour la prochaine alerte, qu'elle vienne de PHP, de WordPress, d'un plugin, de Node.js ou d'une bibliothèque.

Heure 0 : savoir que l'alerte existe

On ne peut pas réagir à ce qu'on ignore. La veille sécurité est la première brique, et elle est moins coûteuse qu'on ne le pense :

• Les annonces officielles des technologies que vous utilisez : flux RSS ou liste de diffusion de php.net, WordPress, votre framework, vos plugins critiques.
• Les alertes des agences : la CISA aux États-Unis, l'ANSSI en France et la DGSSI au Maroc publient des alertes pour les failles majeures. Celle de PHP a été reprise par la CISA le jour même.
• Les avis GitHub (GHSA) et les alertes Dependabot pour les dépendances de vos applications.
• Les communications de votre hébergeur, qui annoncent souvent le déploiement d'un correctif.

Dans le cas de PHP, les identifiants CVE ont fuité la veille, ce qui a avancé la publication. Une veille active permet de préparer la fenêtre de mise à jour avant même que les paquets soient disponibles.

Heure 0 à 1 : l'inventaire répond en dix minutes

La question « quels sites sont concernés ? » ne devrait jamais prendre une journée. Un inventaire à jour liste, pour chaque site ou application : l'hébergement et l'accès, la version de PHP (ou de Node, de Python), le CMS ou le framework et sa version, les plugins ou dépendances critiques, le niveau d'exposition (public, authentifié, interne), le responsable et le dernier contrôle. Avec cet inventaire, l'alerte PHP se traduit immédiatement en une liste : trois sites sur mod_php à traiter en premier, huit sur PHP-FPM corrigés par l'hébergeur à vérifier, un intranet sur 7.4 à migrer ou isoler.

Heure 1 à 2 : prioriser

Tout ne se traite pas en même temps. L'ordre qui limite le risque :

1. Exposition : d'abord les sites publics, ensuite les applications authentifiées, enfin les outils internes.
2. Configuration à risque : pour PHP, Apache avec mod_php avant PHP-FPM, puisque l'exploitation y est démontrée avec les réglages par défaut.
3. Valeur : la boutique qui encaisse des commandes avant la page vitrine.
4. Absence de correctif : les systèmes sur une version sans correctif (PHP 8.1 et antérieur) basculent dans une file à part : mesures temporaires immédiates, puis migration ou mise hors ligne.

Heure 2 à 8 : mettre à jour, dans le bon ordre

Pour chaque système, la même séquence, sans exception :

1. Sauvegarde juste avant l'intervention (fichiers et données), même pour une mise à jour mineure. La règle 3-2-1 assure qu'elle est exploitable.
2. Mise à jour sur un environnement de test quand le changement est significatif (changement de branche PHP, mise à jour majeure d'un plugin). Pour une mise à jour mineure de sécurité, le passage direct en production est acceptable, avec vérification immédiate.
3. Application en production, à une heure creuse si le redémarrage provoque quelques secondes d'indisponibilité.
4. Redémarrage de tout ce qui doit l'être : PHP-FPM ou Apache, files d'attente, workers, conteneurs reconstruits. Un processus de longue durée non redémarré garde la version vulnérable en mémoire. La procédure détaillée est dans mettre à jour PHP sur votre serveur.
5. Mesures temporaires pour les systèmes qui ne peuvent pas être corrigés tout de suite : réglages recommandés par l'éditeur, pare-feu applicatif, restriction d'accès, voire mise hors ligne.

Heure 8 à 12 : vérifier, pas supposer

Une mise à jour lancée n'est pas une mise à jour appliquée. La vérification se fait sur ce qui est réellement servi : la version de PHP vue par le web (pas seulement par le terminal), les parcours critiques (connexion, formulaire, commande, paiement), les journaux d'erreurs, les tâches planifiées. Pour les sites corrigés par un hébergeur, la vérification est encore plus importante, car vous n'avez pas vu l'opération : une version inchangée peut cacher un rétroportage ou une mise à jour non faite ; seule une confirmation explicite tranche.

Heure 12 à 24 : surveiller et chercher les traces

Corriger ferme la porte ; cela ne dit pas si quelqu'un est entré avant. Pendant les jours qui suivent une alerte, surveillez les signes d'une compromission antérieure à la correction :

• Processus PHP qui lancent un shell ou téléchargent des outils (le signal cité par la CISA pour cette faille).
• Fichiers inconnus ou récemment modifiés dans les répertoires web, en particulier les dossiers d'upload.
• Nouveaux comptes administrateurs, tâches planifiées inconnues, clés SSH ajoutées.
• Trafic sortant inhabituel, envois d'emails en masse, pics de charge sans cause.

Un signe confirmé déclenche la procédure d'incident : isolation, analyse, restauration depuis une sauvegarde saine, changement des secrets. Notre guide pour un site piraté détaille cette séquence.

Après 24 heures : capitaliser

Chaque alerte améliore la suivante si l'on prend dix minutes pour noter ce qui a manqué : un site absent de l'inventaire, un accès serveur perdu, un hébergeur injoignable, un plugin qui a bloqué la migration. Ces notes alimentent la checklist de maintenance et, souvent, une décision structurelle : abandonner mod_php pour PHP-FPM, sortir des branches en fin de vie avant qu'elles le soient, changer d'hébergeur, remplacer un plugin abandonné.

Ce plan est ce que vous achetez avec un contrat de maintenance

Une alerte critique un mardi après-midi est le vrai test d'une maintenance de site web. Pas la fréquence des mises à jour de routine : la capacité à répondre en quelques heures, avec un inventaire prêt, des accès valides, un environnement de test et une vérification après coup. C'est ce que nous faisons pour les sites et applications que nous suivons, et ce que nous pouvons mettre en place pour les vôtres. Si l'alerte du 21 octobre vous a pris de court, parlons-en : le premier livrable est l'inventaire, et il change déjà tout.