Une semaine après l’alerte, le travail continue
Un site mis à jour ne signifie pas que tout le système d’information est protégé. Le même moteur PHP peut se trouver dans un serveur, une application installée sur un NAS ou l’interface d’un équipement réseau. Cette dépendance est parfois invisible pour l’utilisateur.
Le 21 octobre, PHP a publié des correctifs pour CVE-2026-109618 et CVE-2026-109619, regroupées sous le nom PHP2Shell. Ces vulnérabilités peuvent permettre une exécution de code à distance sans authentification. Les premières versions correctives sont PHP 8.2.35, 8.3.36, 8.4.27 et 8.5.12. Il faut suivre les mises à jour ultérieures de la branche utilisée ou les paquets corrigés du fournisseur. [Annonce PHP](https://www.php.net/archive/2026.php#2026-10-21-5).
Dans son alerte mise à jour le 27 octobre, le CERT-FR rapporte des tentatives d’exploitation visant certains déploiements. Cela justifie de corriger rapidement, mais ne démontre pas que chaque appareil utilisant PHP a été compromis. [Alerte CERT-FR](https://cert.cyber.gouv.fr/alerte/CERTFR-2026-ALE-014/).
Pourquoi des équipements réseau sont-ils concernés ?
Un routeur est aussi un ordinateur : il dispose d’un système, de services et d’un logiciel d’administration. Certains de ces logiciels utilisent PHP. D’autres reposent sur des technologies différentes.
Pour évaluer l’exposition à PHP2Shell, trois questions comptent : le produit embarque-t-il une version vulnérable de PHP ? Ce composant traite-t-il des requêtes web ? Un attaquant peut-il atteindre le service et les conditions nécessaires à l’exploitation ? La réponse se vérifie pour le modèle, le firmware et les fonctions activées.
Le cas de pfSense est documenté par Netgate. Son avis indique que les vulnérabilités concernent ses installations PHP et souligne deux surfaces à examiner : l’interface d’administration et le portail captif. L’administration est, par défaut, accessible depuis le réseau local, pas depuis Internet ; le portail captif n’est pas activé par défaut. Lorsqu’il est utilisé, ce dernier peut recevoir des requêtes de clients non fiables. [Avis Netgate](https://www.netgate.com/blog/critical-php-security-update).
À l’inverse, Zyxel annonce le 28 octobre que ses produits actuellement commercialisés ne sont pas affectés, car ils n’intègrent pas le paquet PHP vulnérable. Cette conclusion porte sur le périmètre annoncé par le constructeur. [Avis Zyxel](https://www.zyxel.com/global/en/support/security-advisories/zyxel-statement-for-php-core-rce-vulnerabilities-cve-2026-109618-and-cve-2026-109619-10-28-2026).
Pour une box ou un modem fourni par un opérateur, la bonne démarche est donc de vérifier l’avis de l’opérateur et la version du firmware. La présence d’une page de connexion dans le navigateur ne prouve pas l’utilisation de PHP.
Les NAS et les applications embarquées méritent aussi un inventaire
Sur un NAS, le système et les applications installées n’exposent pas nécessairement les mêmes composants. Synology distingue les paquets dépendant de PHP de son composant PHP interne, dont il indique qu’il ne présente pas de surface d’attaque externe. Il faut vérifier les paquets utilisés et les mises à jour disponibles dans le centre de paquets. [Avis Synology](https://www.synology.com/en-us/security/advisory/Synology_SA_26_14).
La même logique d’inventaire peut être appliquée aux passerelles industrielles et aux équipements IoT : demander au fabricant quels composants sont concernés, puis vérifier l’accès réel à ces services. Il s’agit d’une méthode de contrôle, pas d’une affirmation selon laquelle tous ces équipements seraient vulnérables.
Quels impacts en cas de compromission ?
Une exécution de code donne à l’attaquant des possibilités qui dépendent des droits du processus touché. Sur un équipement réseau, les scénarios à examiner comprennent l’accès à des configurations ou à des secrets, la modification de paramètres, l’interruption du service et l’utilisation de l’appareil comme point d’appui vers d’autres systèmes.
Ce sont des conséquences possibles d’une compromission, pas des incidents confirmés pour chaque modèle. Il faut également distinguer le service d’administration du trafic qui traverse l’appareil : une faille PHP ne signifie pas que tous les paquets routés sont automatiquement interceptés ou déchiffrés.
Mettre à jour, puis vérifier
Nous recommandons de commencer par les équipements dont l’administration ou les services web sont accessibles depuis Internet ou un réseau non fiable.
- Recenser le modèle exact, le firmware, les applications installées et la personne responsable de chaque équipement.
- Consulter les avis du constructeur ou de l’opérateur, avec leur date de mise à jour.
- Restreindre les accès d’administration aux réseaux et personnes qui en ont besoin ; vérifier aussi les portails captifs et les accès distants.
- Installer les correctifs par la procédure officielle. Sur un appareil fermé, ne pas remplacer manuellement PHP comme sur un serveur généraliste.
- Vérifier la version réellement utilisée après mise à jour et les redémarrages requis. Tester ensuite les fonctions utiles : accès distant, VPN, portail et applications.
- Documenter les équipements sans correctif et les mesures temporaires ; organiser leur remplacement si leur maintien en sécurité n’est plus possible.
Le CERT-FR rappelle que les contournements provisoires ne remplacent pas les mises à jour. Une modification de configuration copiée sans tenir compte du produit peut aussi perturber son fonctionnement. [Mesures du CERT-FR](https://cert.cyber.gouv.fr/alerte/CERTFR-2026-ALE-014/).
Attention aux avis complémentaires
Le 23 octobre, PHP a signalé CVE-2026-115560, liée à une combinaison particulière de configuration des sessions et de code applicatif. L’éditeur recommande provisoirement de désactiver le suivi de progression des téléversements dans les cas concernés. Pour un équipement intégré, cette vérification doit passer par son fournisseur. [Avis complémentaire PHP](https://www.php.net/archive/2026.php#2026-10-23-1).
L’épisode rappelle pourquoi une campagne de mise à jour doit inclure une veille après le premier correctif : les recommandations évoluent avec les analyses.
Un correctif ne prouve pas l’absence d’intrusion
Si un service vulnérable a été exposé, nous conseillons d’examiner les journaux et les changements de configuration, les comptes inattendus et les connexions inhabituelles. Un signe suspect doit déclencher une analyse, avec conservation des éléments utiles avant toute remise à zéro.
Installer un correctif ferme une vulnérabilité connue ; cela ne retire pas nécessairement un accès déjà installé par un attaquant. L’autorité de cybersécurité de Singapour a également publié des recommandations de surveillance face aux tentatives d’exploitation. [Suivi CSA](https://www.csa.gov.sg/alerts-and-advisories/alerts/al-2026-151/).
Ce que cette alerte change pour vos projets
Pour une PME, le livrable utile est une liste courte : quels équipements sont concernés, qui intervient, quel correctif est installé et quelles vérifications ont été faites. Pour un produit connecté, il faut aussi prévoir l’inventaire des dépendances, la distribution des mises à jour et la durée du support.
Chez Kasual, ces questions relient le développement à l’exploitation : concevoir un produit IoT, préparer les mises à jour à distance et faire vivre une application. La sécurité se maintient pendant toute la vie du produit.
État des informations vérifié le 29 octobre 2026. Les produits cités servent d’exemples documentés ; leur statut et les correctifs doivent être revérifiés avant intervention.
