PHP2Shell : corriger les failles critiques de PHP sans casser la production

Le 21 octobre 2026, le projet PHP a publié en urgence des correctifs pour deux vulnérabilités critiques d’exécution de code à distance, CVE-2026-109618 et CVE-2026-109619, surnommées « php2shell ». Les détails avaient fuité avant la publication, un code d’exploitation circule et des attaques sont observées. La CISA aux États-Unis et le Centre canadien pour la cybersécurité ont publié des alertes demandant de corriger immédiatement.

PHP fait tourner une grande partie du web, mais aussi beaucoup d’outils internes qu’on oublie : interfaces d’administration, outils de supervision, gestionnaires de bases de données, intranets. C’est souvent là que le correctif arrive en dernier. Cet article reprend la méthode que j’ai appliquée sur les environnements dont j’ai la charge : tout recenser, tout corriger, vérifier que rien n’a régressé, puis réduire l’exposition pour la prochaine fois.

Étape 1 : recenser toutes les instances PHP

Le premier risque est d’oublier une machine. Un serveur web public est rarement le seul à exécuter PHP. Dans un parc type, on trouve aussi :

• les interfaces web d’outils d’exploitation, à commencer par le frontend de Zabbix, écrit en PHP ;
• les outils d’administration comme phpMyAdmin, souvent installés « pour dépanner » et jamais retirés ;
• les applications métier et intranets hébergés en interne ;
• les conteneurs, dont l’image embarque sa propre version de PHP, indépendante de celle de l’hôte ;
• les sites gérés par un hébergeur ou un prestataire, pour lesquels il faut obtenir une confirmation écrite de la mise à jour.

Sur chaque machine, il faut contrôler toutes les variantes installées. La version affichée par php -v est celle du binaire en ligne de commande ; le site, lui, passe le plus souvent par PHP-FPM ou par le module Apache, qui peuvent être à une autre version. Je vérifie donc séparément la CLI, chaque pool PHP-FPM et, le cas échéant, le module du serveur web. Une page de diagnostic temporaire, supprimée juste après, ou la commande php-fpm -v pour chaque version installée, permettent de lever le doute.

Étape 2 : tout corriger, serveurs internes compris

Toutes les instances sont mises à jour, sans tri entre « exposées » et « internes ». Un outil interne vulnérable devient la porte d’entrée suivante dès qu’un attaquant a pris pied sur le réseau, et une architecture segmentée limite ce risque sans le supprimer.

Deux points demandent de l’attention :

• Les paquets des distributions : Debian, Ubuntu ou Red Hat rétroportent souvent le correctif sur leur propre version de PHP. Le numéro de version affiché ne correspond alors pas au numéro publié sur php.net. Il faut vérifier dans le journal des modifications du paquet que les deux CVE sont bien mentionnées, plutôt que de comparer des numéros de version.
• Les branches en fin de vie : une version de PHP qui n’est plus maintenue ne reçoit pas de correctif officiel. La page des versions supportées de php.net donne les dates de fin de support de chaque branche. Une application encore sur une branche en fin de vie doit être migrée, ou isolée en attendant, et ce chantier ne peut plus être repoussé.

Enfin, installer le paquet ne suffit pas : les processus PHP-FPM et le serveur web continuent d’exécuter l’ancien code tant qu’ils ne sont pas redémarrés. Je redémarre explicitement les services, puis je contrôle la version réellement chargée.

Étape 3 : vérifier la non-régression, même sur une mise à jour de sécurité

Une mise à jour de sécurité sur une branche maintenue change peu de code, et les régressions sont rares. Rares ne veut pas dire inexistantes : une extension compilée à part, un comportement modifié à la marge, un cache d’opcodes qui ne se vide pas comme prévu suffisent à faire tomber un site. Sur une correction d’urgence, la tentation est de pousser partout en même temps. Je procède autrement, avec une vérification courte mais systématique :

1. Point de retour arrière : sauvegarde ou instantané de la machine virtuelle avant la mise à jour. Sous Proxmox VE comme sous VMware, cela prend quelques secondes.
2. Premier lot : une machine de recette ou un serveur peu critique, mis à jour en premier.
3. Contrôles fonctionnels : pages principales, connexion, formulaires, tâches planifiées en PHP, appels d’API. Une courte liste écrite à l’avance évite d’improviser.
4. Journaux : lecture des journaux d’erreurs PHP et du serveur web juste après le redémarrage, à la recherche d’avertissements nouveaux.
5. Supervision : temps de réponse et taux d’erreurs suivis pendant quelques heures dans l’outil de supervision.
6. Généralisation : le reste du parc, par lots, en gardant le point de retour arrière jusqu’à la validation.

Sur une faille exploitée activement, cette séquence se compte en heures, pas en semaines. Elle évite surtout de découvrir une régression sur tout le parc à la fois.

Étape 4 : chercher des traces de compromission

Corriger ferme la porte, mais ne dit pas si quelqu’un est entré avant. Quand une faille a été exploitée avant la publication du correctif, il faut vérifier :

• les fichiers PHP créés ou modifiés récemment dans les répertoires web, en particulier dans les dossiers d’upload ou de cache où aucun script ne devrait se trouver ;
• les processus lancés par l’utilisateur du serveur web ou de PHP-FPM, qui n’a normalement aucune raison d’ouvrir un shell ;
• les connexions sortantes inhabituelles depuis les serveurs web ;
• les requêtes suspectes dans les journaux d’accès, à rapprocher des indicateurs publiés par les éditeurs de sécurité.

Un SIEM comme Wazuh, avec le contrôle d’intégrité des fichiers activé sur les répertoires web, facilite beaucoup ce travail : il signale les fichiers modifiés et conserve l’historique. En cas de doute sérieux, la bonne réponse est de reconstruire la machine à partir d’une source saine plutôt que de la nettoyer.

Étape 5 : masquer les versions du serveur web et de PHP

Ce n’est pas la réponse principale à une faille : seule la mise à jour corrige la vulnérabilité. C’est en revanche une mesure simple, qui ne coûte rien et qui devrait figurer dans toutes les configurations. Les robots qui balaient Internet cherchent d’abord les serveurs qui annoncent une version vulnérable. Un serveur qui ne l’affiche pas sort de ces listes faciles et oblige l’attaquant à tester, ce qui laisse davantage de traces.

• PHP : expose_php = Off dans le fichier php.ini, pour supprimer l’en-tête X-Powered-By qui donne la version exacte.
• Apache : ServerTokens Prod et ServerSignature Off, pour que l’en-tête Server et les pages d’erreur n’affichent plus la version ni le système.
• nginx : server_tokens off; dans le bloc http, avec le même effet sur l’en-tête et les pages d’erreur.
• Les autres serveurs web et les proxys : le principe est le même, en vérifiant aussi les répartiteurs de charge et les reverse proxys placés devant, qui ajoutent parfois leurs propres en-têtes.

Un simple curl -I sur le site, avant et après, permet de vérifier que les en-têtes ne révèlent plus rien. Je l’ajoute aux contrôles de fin de chantier, au même titre que le reste du durcissement.

Ce qu’il faut retenir pour la prochaine fois

• Tenir à jour l’inventaire des instances PHP, conteneurs et outils internes compris.
• Avoir une procédure de mise à jour d’urgence écrite : point de retour arrière, premier lot, contrôles, généralisation.
• Suivre les avis de sécurité de PHP, du CERT-FR et des distributions utilisées.
• Planifier la sortie des branches en fin de vie avant qu’une faille ne l’impose.
• Appliquer le durcissement de base partout, dont le masquage des versions.

Ces mesures relèvent de l’hygiène d’exploitation, et c’est justement ce qui manque le plus souvent quand une faille critique tombe. Un audit de l’infrastructure permet de faire l’inventaire et de mesurer l’exposition ; le durcissement et la segmentation font partie de l’offre cybersécurité et Zero Trust, et je peux aussi mener le chantier avec votre équipe en intégration en régie.

À lire aussi

• NIS2 : la loi Résilience reportée, que faire dès maintenant ?
• Cyber Resilience Act : signalement sous 24 h, ce que cela change pour la GTB et l’IoT
• Réalisation : Smart Building et architecture Zero Trust

Sources

• The PHP Foundation : Today’s PHP Security Release, and How We’re Strengthening PHP Security
• CISA : Critical Vulnerabilities in PHP Require Immediate Patching
• Centre canadien pour la cybersécurité : alerte AL26-026, vulnérabilités critiques touchant PHP
• IT-Connect : php2shell, correctifs d’urgence pour CVE-2026-109618 et CVE-2026-109619
• Tenable : php2shell, questions fréquentes
• Sophos : code d’exploitation publié pour les vulnérabilités PHP
• php.net : versions supportées et dates de fin de support
• Documentation PHP : directive expose_php
• Documentation Apache : ServerTokens et ServerSignature
• Documentation nginx : server_tokens