PHP, Stormshield
patcher une faille critique en 7 étapes

Les faits, d'abord

Le 21 octobre 2026, deux vulnérabilités critiques ont été publiées dans PHP : CVE-2026-109618 et CVE-2026-109619, surnommées « php2shell ». Elles permettent une exécution de code à distance non authentifiée et touchent toutes les installations PHP qui servent des requêtes web. La CISA a publié une alerte le jour même, avec une consigne simple : inventorier, puis corriger en priorité les systèmes exposés à Internet.

Sources : alerte CISA du 21/10/2026 (cisa.gov) et avis officiel php.net. Sur Ubuntu 24.04, la correction arrive par un backport de la branche 8.3, c'est la version du paquet qu'il faut vérifier, pas le numéro affiché par php -v.

Ce qu'un éditeur doit dire pendant un incident

Le même jour, une partie de nos clients recevait la communication suivante, nous la reproduisons telle quelle, parce qu'elle illustre ce qu'on attend d'un fournisseur sous pression :

Ce texte fait quatre choses, dans l'ordre : il nomme la cause (les deux CVE), il nomme le service touché, il sépare explicitement ce qui ne marche plus de ce qui marche encore, et il donne une date de prochaine nouvelle. C'est exactement la structure qu'il faut, et ce n'est pas anodin quand l'éditeur est aussi celui qui vous vend le pare-feu.

Deux enseignements pour nous, exploitants : une sauvegarde qui dépend d'un service tiers hébergé cesse d'exister le jour où ce service est en maintenance, et il faut une copie locale. La phrase « vos données actuelles sont en sécurité » n'est vraie que si la restauration a été testée.

Comment on patche, concrètement

Un correctif d'urgence n'est pas un apt upgrade lancé à l'aveugle. Notre séquence, celle que nous avons appliquée sur notre propre parc :

1. 1
   Inventorier avant de toucher PHP est rarement seul : il est dans des paquets, des conteneurs, des appliances et des dépendances d'applications. La CISA le dit explicitement, la prévalence n'est pas observable directement. On liste les versions réellement servies, pas celles du dépôt.
2. 2
   Corriger d'abord ce qui est exposé Internet d'abord, puis les systèmes internes, puis les postes. Un serveur interne non exposé peut attendre une fenêtre de maintenance ; une page de connexion publique, non.
3. 3
   Passer par le paquet de la distribution Sur Debian et Ubuntu, la version corrigée arrive comme backport : on vérifie le numéro de paquet (apt policy php8.3-fpm), on n'installe pas un PHP compilé à la main sur un serveur de production. Les dépôts doivent être en HTTPS si le port 80 sortant est filtré.
4. 4
   Redémarrer les bons processus Mettre à jour le paquet ne suffit pas : ce sont les processus PHP-FPM qui doivent être relancés. Puis on recharge le frontal web sans le couper : nginx -s reload ou systemctl reload apache2, jamais un redémarrage à l'aveugle. Penser à vider OPcache.
5. 5
   Vérifier ce qui est réellement servi Le numéro affiché par php -v n'est pas la preuve : c'est celui du binaire en ligne de commande. On vérifie le handler du site, la version du module chargé, et on teste l'application. Sur Apache, le piège classique est un AddType application/x-httpd-php ou un a2dismod oublié : le site continue de tourner sur l'ancienne version sans que rien ne le signale.
6. 6
   Ne pas patcher dans les conteneurs Une image se reconstruit sur une base corrigée et se redéploie. Un correctif appliqué à la main dans un conteneur disparaît au prochain déploiement, et laisse croire que le parc est à jour.
7. 7
   Si on ne peut pas patcher tout de suite Palliatifs assumés et datés : pare-feu applicatif en amont, filtrage des uploads, retrait du service de l'exposition publique. La CISA mentionne le WAF comme protection temporaire, temporaire, pas définitive.

Les pare-feux non plus ne sont pas épargnés

Une appliance de sécurité exposée sur Internet est un serveur comme un autre : elle a des versions, des correctifs et des vulnérabilités. Les exemples récents ne manquent pas, et Fortinet en fournit deux qui ont servi de leçon à toute la profession.

Ce que ces deux affaires disent, au-delà de la marque : l'interface d'administration d'un pare-feu ne doit jamais être joignable depuis Internet, le VPN doit être patché comme une application publique, et l'authentification à deux facteurs n'est pas une option. Fortinet publie des avis détaillés, avec les versions corrigées et les contournements, encore faut-il les lire le jour de leur publication. CISA publie de son côté des alertes pour les vulnérabilités réellement exploitées.

Du côté de Stormshield, les avis sont publiés sur advisories.stormshield.eu, avec la version produit et l'indice de gravité. Nous sommes intégrateur et exploitant de ces équipements, pas éditeur : les correctifs et les certifications restent ceux de Stormshield, notre travail est de les appliquer et de le prouver.

Nos liens avec Stormshield, et le suivi des tests

Nous intégrons et exploitons des équipements Stormshield chez nos clients : pare-feux, protections des postes, et la brique de sauvegarde dont il était question plus haut. Ce positionnement a une conséquence simple : nous ne choisissons pas les correctifs, nous les appliquons, et nous devons pouvoir dire, pour chaque client, quelle version tourne, quel avis la concerne et quand elle a été appliquée.

Le suivi est un cycle, pas un événement :

• Avant un état des lieux : versions, règles, exposition, comptes d'administration, sauvegarde de la configuration. Sans cet état initial, aucun test n'est interprétable.
• Pendant des tests de sécurité menés avec l'accord écrit du client, sur une fenêtre annoncée : recherche de services exposés, vérification des règles, tentative de contournement des accès distants, contrôle de la journalisation.
• Après chaque constat reçoit une correction, une date et un re-test. Un rapport sans re-test est un document, pas un résultat.

Surveiller les serveurs : Wazuh, héritier d'OSSEC

Un pare-feu arrête ce qui entre. Il ne dit pas qu'un fichier du serveur a changé à trois heures du matin. C'est le rôle d'un HIDS système de détection d'intrusion sur l'hôte, et c'est ce que nous déployons chez les clients qui nous confient des serveurs.

La filiation est utile à connaître : OSSEC est l'ancêtre, un HIDS libre apparu en 2004, toujours maintenu et encore parfaitement utilisable. Wazuh en est le descendant direct, qui ajoute un tableau de bord, un indexeur, la corrélation d'alertes et la conformité. Nous avons testé les deux, et nous exploitons Wazuh sur nos propres serveurs : un agent sur chaque machine, un gestionnaire central, et les journaux qui remontent.

Ce que nous surveillons concrètement, module par module :

Les limites, dites franchement : un SIEM ne corrige rien, il constate. Il produit des faux positifs tant qu'il n'est pas réglé, comptez plusieurs semaines avant que le bruit descende. Et le gestionnaire ne doit jamais être exposé sur Internet : il collecte les journaux de tout le parc, c'est une cible de premier choix.

Nettoyer le trafic DNS : l'amplification, ce multiplicateur discret

Voici le problème le plus sous-estimé d'un réseau d'entreprise, et le plus simple à mesurer. Une requête DNS tient en quelques dizaines d'octets ; la réponse peut en faire plusieurs milliers. Le rapport entre les deux est le facteur d'amplification et il se compte en dizaines.

Conséquence : un serveur DNS qui répond à n'importe qui depuis Internet n'est pas un service, c'est une arme par réflexion. Un attaquant envoie des requêtes avec l'adresse source de sa victime, c'est de l'usurpation, rien de plus simple en UDP, et tous les résolveurs ouverts du monde répondent à cette victime. Une bande passante d'attaque de 1 Gb/s en requêtes peut produire des dizaines de Gb/s de réponses. C'est ce qu'on appelle un effet de multiplication, et c'est la raison pour laquelle les attaques par amplification DNS restent, année après année, parmi les plus volumineuses observées.

Le nettoyage se fait à trois endroits. Sur le résolveur : récursion restreinte aux réseaux légitimes, refus des requêtes hors zone, limitation de débit, taille de réponse plafonnée. Sur le pare-feu : le port 53 sortant ne doit pas laisser passer des requêtes vers n'importe quel résolveur, seuls nos résolveurs désignés sont joignables. Et sur le réseau : le filtrage anti-usurpation en amont, sans lequel une machine compromise chez nous peut émettre avec l'adresse d'un autre.

Pourquoi c'est aussi notre intérêt direct : un résolveur ouvert sur le réseau d'un client devient une arme pointée vers un tiers, son adresse se retrouve dans les listes de blocage, et c'est son lien, souvent le plus cher de l'île, qui sature le premier. Nettoyer son DNS, c'est se protéger et protéger le voisin.

Et ce n'est pas le seul protocole dans ce cas. Les mêmes tests s'appliquent au NTP, au SSDP et à memcached : trois services légitimes qui, mal configurés et exposés, offrent des facteurs d'amplification du même ordre. La règle est toujours la même : un service UDP exposé sur Internet doit être inventorié, limité et filtré, ou ne pas être exposé du tout.

Ce que nous retenons

• Une vulnérabilité n'est pas un incident tant qu'elle n'est pas exploitée mais on ne peut pas le savoir, donc on patche comme si elle l'était.
• La sauvegarde doit exister deux fois une copie locale, une copie distante. Le jour où le service distant est en maintenance, la copie locale est la seule qui compte.
• La preuve datée vaut mieux que la promesse version avant, version après, date, opérateur. C'est ce que nous remettons après une intervention.
• Le retour arrière fait partie du correctif un instantané ou une sauvegarde avant de toucher, sinon on ne corrige pas, on parie.

Nous ne promettons pas un parc sans faille. Nous promettons de savoir quoi faire quand une faille sort, et de pouvoir revenir en arrière si le correctif casse quelque chose.