Faille PHP2Shell : comment nous avons protégé les serveurs de nos clients

Le 21 octobre 2026, les correctifs de PHP2Shell (CVE-2026-109618 et CVE-2026-109619) sont publiés. Deux failles notées 9,2 sur 10, dans l’interpréteur PHP lui-même : exécution de code à distance, sans authentification, sur à peu près tout ce qui fait tourner PHP sur le web. Les premières tentatives d’exploitation sont observées le jour même.

Dans ce genre de situation, la question n’est pas de savoir si un serveur est touché. C’est de savoir en combien de temps il sera corrigé. Voici comment nous avons traité la faille chez les clients dont nous gérons les serveurs.

Jour 0, le soir : l’inventaire

Avant de corriger quoi que ce soit, il faut savoir précisément ce qui tourne. Le soir même de la publication, nous avons contrôlé chaque serveur que nous administrons :

• les versions de PHP installées, paquet par paquet ;
• la façon dont PHP sert réellement les pages (PHP-FPM, module Apache, CGI) ;
• la provenance des paquets et la disponibilité d’un correctif pour chacun.

Ce contrôle évite deux pièges. Le premier : les distributions Linux intègrent souvent le correctif sans changer le numéro de version affiché, si bien qu’un serveur peut sembler vulnérable alors qu’il est corrigé, ou l’inverse. Le second : plusieurs versions de PHP cohabitent souvent sur une même machine, et ce n’est pas toujours celle qu’on croit qui répond aux visiteurs. Sur l’un des serveurs, le diagnostic initial visait le mauvais composant : seul le contrôle de ce qui tournait réellement l’a montré.

Trois situations, trois réponses

L’inventaire a donné trois cas de figure.

• Le correctif est disponible. Mise à jour des seuls paquets PHP concernés, redémarrage des services, vérification. C’est le cas le plus fréquent, et le plus rapide.
• Le correctif arrive, mais pas tout de suite. Nous posons une protection provisoire dès le premier jour : désactivation de la fonction de PHP qui sert de porte d’entrée à l’attaque, filtrage en amont, voire isolement de l’application. Cela ne remplace pas la correction, mais réduit fortement le risque en attendant.
• Aucun correctif officiel n’est prévu. Une boutique en ligne ou une application métier ne change pas de système en une semaine sans risque de tout casser. Quand l’éditeur ne publie rien pour une version donnée, nous construisons nous-mêmes le paquet corrigé à partir du correctif officiel de PHP, nous le testons dans un environnement identique à la production, puis nous l’installons. Le client est protégé tout de suite, et la montée de version se planifie ensuite, à froid.

La règle : jamais d’intervention sans retour arrière

Sur chaque serveur, avant toute modification :

• sauvegarde de la configuration et de la liste exacte des paquets installés ;
• sauvegarde des bases de données quand l’intervention le justifie ;
• procédure de retour arrière écrite et prête à lancer ;
• simulation de la mise à jour pour vérifier qu’elle ne supprime ni n’ajoute rien d’inattendu.

Nous n’avons eu à utiliser aucun retour arrière. Mais c’est leur existence qui permet d’intervenir vite sans prendre de risque.

La nuit, puis le contrôle

Les mises à jour ont été faites la nuit. Côté visiteurs, elles se sont traduites par le redémarrage de PHP ou d’Apache : quelques secondes.

Après chaque intervention, nous avons vérifié que la nouvelle version était bien celle qui servait les pages, que les modules PHP étaient identiques à avant, que les pages clés répondaient (y compris le panier et le paiement sur les boutiques) et que les journaux d’erreurs ne montraient rien de nouveau. Nous avons aussi contrôlé l’intégrité des fichiers des sites, pour écarter une compromission survenue avant la correction.

Le bilan

• Inventaire complet le soir de la publication des correctifs.
• Les serveurs pour lesquels un correctif existait : corrigés dans les 48 heures.
• Les autres : protégés provisoirement, puis corrigés avec un paquet construit sur mesure, le dernier une semaine après la publication.
• Aucun site cassé, aucun retour arrière nécessaire.

Vous gérez des serveurs PHP, en interne ou avec un prestataire, et vous n’êtes pas certain qu’ils soient corrigés ? Voyez notre page sur la faille PHP2Shell (versions touchées, atténuations, intervention) ou décrivez-nous votre situation. Des signes d’intrusion ? Passez directement par notre intervention sur incident cyber.