PHP2Shell : une faille critique qui concerne aussi les bâtiments connectés

*Pour qui : *Exploitants et propriétaires de bâtiments, intégrateurs, bureaux d’études et responsables informatiques.

Mis à jour le 22 octobre 2026. La situation évolue : nous compléterons cet article si les avis officiels changent.

Le 21 octobre 2026, l’équipe de PHP a publié en urgence des correctifs pour deux failles critiques, surnommées « PHP2Shell ». Ce langage fait tourner une grande partie des sites web dans le monde, mais aussi de nombreuses interfaces d’équipements techniques. C’est pourquoi cette alerte ne concerne pas seulement les sites internet.

En bref (au 22 octobre 2026)

• Deux failles de PHP, CVE-2026-109618 et CVE-2026-109619, peuvent permettre dans certaines configurations de prendre le contrôle d’un serveur à distance, sans mot de passe.
• Le problème est mondial : PHP est utilisé partout, et les agences de cybersécurité de plusieurs pays ont publié des alertes, dont le CERT-FR en France et le NCSC au Royaume-Uni.
• Le NCSC demande aussi de surveiller les mises à jour des fabricants pour les équipements qui intègrent PHP. Les installations techniques des bâtiments font partie des systèmes à vérifier.

Une alerte mondiale en 48 heures

Les détails des deux failles devaient être rendus publics de façon coordonnée le 22 octobre. Selon la société de sécurité watchTowr, ils ont fuité sur les réseaux sociaux dès le 20 octobre, avant même la sortie des correctifs. L’équipe de PHP a donc publié ses mises à jour en urgence le 21 octobre, après les avoir transmises à l’avance aux distributions Linux et aux éditeurs qui assurent un support à long terme.

PHP n’est pas un logiciel parmi d’autres : il est installé sur des millions de serveurs dans le monde. En quelques heures, l’alerte a été relayée par les agences de cybersécurité de plusieurs pays. Au Royaume-Uni, le NCSC renvoie même vers un inventaire des produits concernés tenu par son homologue néerlandais, le NCSC-NL.

Ce que l’on sait (au 22 octobre 2026)

Confirmé par les sources officielles :

• PHP a corrigé deux vulnérabilités critiques, notées 9,2 sur 10. Elles peuvent permettre l’exécution de code à distance sans authentification.
• Les versions corrigées sont PHP 8.5.12, 8.4.27, 8.3.36 et 8.2.35.
• Le projet PHP ne maintient plus les versions 8.1 et antérieures. Vu la gravité des failles, son équipe de sécurité a toutefois publié des correctifs minimaux pour les versions 7.4, 8.0 et 8.1, et certaines distributions et éditeurs proposent des correctifs rétroportés.
• Selon l’équipe de PHP, le risque concerne toutes les installations qui traitent des requêtes web, et il est le plus élevé avec le module mod_php d’Apache.
• Le CERT-FR indique avoir connaissance de preuves de concept. Le NCSC britannique recommande de mettre à jour sans attendre et, si aucune mesure ne peut être appliquée rapidement, d’envisager de déconnecter le système.

Rapporté par une société de sécurité :

• watchTowr indique avoir observé des tentatives d’exploitation sur son réseau de pièges (honeypots) depuis le 21 octobre. Ces observations ne concernent pas, à ce stade, des incidents confirmés dans des bâtiments connectés.

Ce qui reste à confirmer

• L’ampleur réelle des attaques : au 22 octobre, ni le CERT-FR ni le NCSC ne font état d’une exploitation active, et l’agence américaine CISA n’avait pas inscrit ces failles à son catalogue des vulnérabilités exploitées, selon watchTowr, ce qui ne prouve pas l’absence d’attaques.
• La liste des équipements et logiciels concernés, que les fabricants sont en train d’établir.

Pourquoi les bâtiments connectés sont-ils concernés ?

PHP est d’abord connu comme le langage de nombreux sites web. Mais il est aussi présent ailleurs.

Beaucoup d’équipements techniques disposent d’une interface web embarquée, accessible depuis un navigateur :

• Les superviseurs de GTB et les serveurs de visualisation ;
• Les passerelles entre protocoles ;
• Les routeurs, les pare-feu et les points d’accès Wi-Fi ;
• Les serveurs de stockage (NAS) et certains enregistreurs.

Cette liste ne signifie pas que ces équipements sont vulnérables. Selon les fabricants, ces interfaces peuvent reposer sur PHP, sur un autre langage ou sur un serveur web spécifique. Seul le fabricant peut dire si son équipement utilise PHP, et dans quelle version. À l’inverse, ne pas savoir si un équipement utilise PHP ne prouve pas qu’il est protégé.

C’est précisément ce que souligne le NCSC britannique. Il demande aux organisations de surveiller les mises à jour des fabricants de logiciels tiers, « y compris pour les équipements et services qui peuvent intégrer PHP ».

Les grands constructeurs ont commencé leurs vérifications. Cisco, par exemple, examine une longue liste de ses produits (réseau, sécurité, Wi-Fi, téléphonie). Au 22 octobre, aucun n’était connu comme affecté, et Cisco indiquait n’avoir connaissance d’aucune utilisation malveillante de ces failles.

Le vrai piège : les équipements qu’on ne met jamais à jour

Sur un serveur web classique, la réponse est simple : installer la version corrigée de PHP.

Pour un équipement technique, c’est différent. Le logiciel est intégré dans le firmware du fabricant. L’exploitant ne peut pas mettre PHP à jour lui-même : il doit attendre, puis installer, une mise à jour fournie par le fabricant.

Or les équipements anciens embarquent souvent des versions anciennes de PHP, et le CERT-FR rappelle que les versions 5.x, 7.x, 8.0.x et 8.1.x ne sont plus maintenues. Des correctifs existent pour certaines d’entre elles, mais encore faut-il que le fabricant les intègre dans une mise à jour de son firmware.

On retrouve un scénario comparable à celui de l’incident récent des contrôleurs de réfrigération. Selon Danfoss, la majorité des unités touchées étaient des produits anciens, qui ne recevaient plus de mises à jour, et le CERT-FR rappelait que leurs interfaces n’auraient pas dû être exposées sur Internet. Nous l’avons détaillé dans notre article sur la cybersécurité des bâtiments connectés.

Que faire dès maintenant ?

1. Inventorier les interfaces web. Lister les équipements techniques qui disposent d’une interface accessible par navigateur, et vérifier lesquels sont joignables depuis Internet ;
2. Ne rien exposer directement sur Internet. Le CERT-FR recommande d’isoler les équipements concernés. L’accès à distance doit passer par un VPN ou un accès filtré, jamais par une interface ouverte. Ces mesures réduisent l’exposition, mais ne corrigent pas la faille ;
3. Interroger les fabricants et les intégrateurs. Demander si l’équipement utilise PHP, quelle version, et si un correctif est prévu ;
4. Appliquer les mises à jour dès leur publication. Pour les serveurs que vous gérez vous-même, passer à une version corrigée de PHP. L’équipe de PHP précise que ses mesures temporaires ne rendent pas une installation sûre : elles ne remplacent pas la mise à jour ;
5. Rechercher les signes de compromission. Avant de corriger un système exposé, le NCSC conseille de vérifier qu’il n’a pas déjà été compromis, par exemple par une porte dérobée installée par un attaquant ;
6. Déconnecter en dernier recours. Si un système exposé ne peut être ni corrigé ni protégé rapidement, le NCSC recommande d’envisager de le mettre hors ligne.

Questions fréquentes

Mon bâtiment est-il concerné si je n’ai pas de site web ?

Peut-être. La question n’est pas d’avoir un site web, mais de savoir si vos équipements techniques ont une interface web basée sur PHP. Seul le fabricant de chaque équipement peut le confirmer.

Comment savoir si un équipement utilise PHP ?

En consultant les avis de sécurité du fabricant, ou en lui posant directement la question, avec la référence exacte et la version du firmware. Votre intégrateur peut vous aider à faire cet inventaire.

Faut-il couper les équipements tout de suite ?

Pas forcément. La priorité est de vérifier qu’ils ne sont pas joignables directement depuis Internet. La déconnexion n’est conseillée qu’en dernier recours, pour un système exposé qui ne peut être ni corrigé ni protégé rapidement.

Conclusion : une leçon qui dépasse PHP

Cette faille sera corrigée, comme d’autres avant elle. Mais elle rappelle une réalité : un bâtiment connecté contient des dizaines de logiciels que personne ne voit, et dont il faut connaître l’existence pour les protéger.

Les installations qui résistent le mieux sont celles qui ont été pensées pour cela dès la conception : un inventaire à jour, des réseaux cloisonnés, des accès distants maîtrisés et un plan de mise à jour pour toute la durée de vie des équipements.

Un bâtiment intelligent ne doit pas seulement être bien intégré. Il doit aussi pouvoir être maintenu et sécurisé dans le temps.

Chez ExaBuilding, cette exigence fait partie de chaque projet, de l’audit des installations existantes à la conception et l’intégration de nouveaux systèmes.

Vous voulez savoir si vos installations techniques sont exposées ? Parler à un expert

Note : cet article fait le point au 22 octobre 2026, à partir des avis officiels disponibles à cette date. Pour chaque équipement, l’avis de sécurité du fabricant fait foi.

Sources

Sources officielles

• PHP, avis de sécurité du 21 octobre 2026 sur CVE-2026-109618 et CVE-2026-109619 (PHP 8.5.12, 8.4.27, 8.3.36 et 8.2.35) : https://www.php.net/archive/2026.php
• CERT-FR (ANSSI), alerte CERTFR-2026-ALE-014 « Multiples vulnérabilités dans PHP », 21 octobre 2026, mise à jour le 22 octobre 2026 : https://cert.cyber.gouv.fr/alerte/CERTFR-2026-ALE-014/
• NCSC (Royaume-Uni), « Critical security issue affecting PHP », 21 octobre 2026, mis à jour le 22 octobre 2026 : https://www.ncsc.gov.uk/news/critical-security-issue-affecting-php

Fabricant

• Cisco, « Vulnerabilities in PHP Affecting Cisco Products: October 2026 », 21 octobre 2026, version 1.2 du 22 octobre 2026 : https://sec.cloudapps.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-php-october26-Jj384Daq

Société de sécurité

• watchTowr, « PHP2Shell FAQ: CVE-2026-109618 & CVE-2026-109619 », 20 octobre 2026, mis à jour le 22 octobre 2026 : https://watchtowr.com/intelligence/php-cve-2026-109618-faq/