Comment mettre à jour les sites de vos clients en 4 étapes ?
Faites l’inventaire, corrigez, protégez le référencement si vous devez couper, puis vérifiez qu’aucun site n’a été visité.
Étape 1. Relever la version PHP de chaque site
Il vous faut le numéro complet, par exemple 8.3.36, pas seulement « 8.3 ». Trois endroits pour le trouver :
- WordPress : Outils, puis Santé du site, onglet Infos, rubrique Serveur.
- cPanel : le sélecteur de version PHP (MultiPHP Manager ou « Select PHP Version », selon l’hébergeur). Plesk : les paramètres PHP du domaine.
- Sinon : demandez la version à l’hébergeur.
Notez le tout dans un tableau simple : site, hébergeur, version relevée, date du correctif. Il vous servira pour l’étape 4 et pour vos clients.
Étape 2. Mettre à jour PHP ou relancer l’hébergeur
Sur un serveur que vous gérez, faites une sauvegarde, installez la version corrigée depuis les paquets de votre distribution, puis redémarrez PHP et le serveur web. Selon PHP, les distributions Linux et les éditeurs de versions à support long ont reçu les correctifs en avance.
Sur un hébergement mutualisé, écrivez au support. Voici un message à adapter :
Bonjour, suite à l’avis de sécurité PHP du 21 octobre 2026 (CVE-2026-109618 et CVE-2026-109619), pouvez-vous me confirmer que le serveur qui héberge [domaine] tourne sur une version corrigée (8.5.12, 8.4.27, 8.3.36 ou 8.2.35) ou dispose d’un correctif rétroporté ? Merci de m’indiquer la date d’application.
Si vous administrez le serveur et ne pouvez pas mettre à jour tout de suite, PHP propose des mesures provisoires. La plus simple désactive le suivi de progression des envois de fichiers dans php.ini (pas dans un .user.ini), puis demande de redémarrer tous les processus PHP :
session.upload_progress.enabled = 0
À noter : ce réglage ne couvre que CVE-2026-109619. Il fait gagner du temps, il ne remplace pas la mise à jour.
Étape 3. Si vous devez couper un site, renvoyer une erreur 503
Le 21 octobre, John Mueller (Google) a rappelé la règle : un site coupé pour un correctif d’urgence doit répondre avec un code HTTP 503, pas laisser les requêtes échouer, ni renvoyer une 404 ou une 500. Vous pouvez le faire en dehors de PHP, depuis votre CDN ou en pointant le domaine ailleurs.
La documentation de Google précise trois points :
- le 503 convient pour une coupure de 1 à 2 jours, avec un en-tête
Retry-After qui indique le retour prévu ;
- le fichier
robots.txt ne doit jamais répondre en 503, sinon Google cesse d’explorer tout le site ;
- les codes 404 et 410, ou une balise
noindex, retirent les pages des résultats.
Au-delà de quelques jours, Google conseille plutôt une page d’accueil temporaire, indexable, en code 200.
Étape 4. Chercher des traces d’intrusion
Les attaques ont commencé avant la publication des correctifs. Wordfence conseille de conserver les journaux du serveur et du pare-feu depuis au moins 48 heures avant le 21 octobre. Sucuri recommande de vérifier quatre points :
- des fichiers PHP que vous ne reconnaissez pas ;
- des tâches planifiées (cron) ajoutées ;
- des comptes administrateur inconnus ;
- des connexions sortantes suspectes depuis le serveur.
Sur WordPress, nos 6 conseils pour sécuriser un site contre le piratage vous aident à faire ce tour. Si vous trouvez quelque chose, suivez le plan d’urgence de notre guide Sécuriser son site web : 12 réflexes : garder les preuves, corriger, changer tous les mots de passe, puis restaurer une sauvegarde saine.
À retenir : l’inventaire des versions est l’étape qui conditionne toutes les autres, commencez par là.
