Les failles PHP Freebox ne prouvent pas que près de deux millions de box sont vulnérables. Le chiffre de 1,97 million correspond à des hôtes IP français classés comme utilisant PHP, pas à des foyers ni à des appareils piratables. Au 21 octobre 2026, deux vulnérabilités PHP notées 9,2 sur 10 étaient confirmées, mais les composants touchés et les conditions d’exploitation restaient à publier.
Les Freebox sont-elles réellement touchées par les failles PHP ?
Rien ne permettait, au 21 octobre 2026, d’affirmer que les deux failles PHP critiques affectaient Freebox OS. L’annonce officielle du projet PHP ne précisait ni les composants vulnérables, ni les versions touchées, ni les prérequis d’exploitation. Le rapprochement avec les Freebox reposait principalement sur des résultats de détection automatisée.
PHP est un langage exécuté côté serveur : il produit notamment des pages web à partir d’un programme traité sur la machine qui héberge le service. Une adresse se terminant par « .php » ne démontre toutefois pas qu’un interpréteur PHP, c’est-à -dire le logiciel qui exécute ce langage, fonctionne derrière l’interface.
Le 21 octobre 2026, Frandroid a indiqué, selon ses propres informations, que Freebox OS n’exécutait pas de serveur PHP. Les fichiers de modèle porteraient une extension « .php », mais seraient traités par un logiciel développé par Free. Cette explication rend plausible un faux positif, sans constituer une confirmation primaire de l’opérateur puisque aucune déclaration publique de Free allant dans ce sens n’avait été retrouvée dans les sources examinées.
Le piège est classique : un scanner reconnaît un indice technique, puis cet indice devient abusivement une preuve de vulnérabilité. Le même problème existe avec de nombreux équipements connectés exposés à Internet : visibilité, identification du logiciel et possibilité d’attaque sont trois constats distincts.
Que signifie vraiment le chiffre de 1,97 million d’hôtes ?
Le chiffre de 1,97 million désigne des hôtes IP observés en France et classés comme utilisant PHP, selon des données d’Infrawatch relayées le 21 octobre 2026. Ce total ne correspond ni à 1,97 million de Freebox confirmées, ni à 1,97 million de foyers distincts, ni à autant de systèmes exploitables.
Sur une période de 48 heures, les chiffres relayés faisaient état d’environ 4,3 à 4,38 millions d’hôtes observés dans le monde, dont 1,97 million en France. Ils mentionnaient aussi 11 millions d’observations de services ou de ports, dont 6,62 millions en France. Un même hôte peut exposer plusieurs services ; additionner ces observations comme s’il s’agissait d’appareils uniques fausse donc l’analyse.
| Signal observé | Ce qu’il établit | Ce qu’il n’établit pas |
|---|---|---|
| URL ou fichier en « .php » | Une convention de nommage visible | La présence d’un interpréteur PHP actif |
| 1,97 million d’hôtes IP français | Des hôtes classés comme utilisant PHP | Deux millions de Freebox ou de foyers vulnérables |
| 6,62 millions de services ou ports en France | Des observations de services réseau | 6,62 millions d’appareils distincts |
| Deux scores CVSS v4.0 de 9,2 | Une sévérité potentielle critique | Une exploitation possible sur toute interface détectée |
Frandroid estimait également, dans une analyse publiée le 21 octobre 2026, que le retrait des faux positifs attribués à Free et Iliad ramènerait le total français autour de 250 000 services, contre 786 283 aux États-Unis. Ce calcul reste une information à source unique. Il ne doit pas être traité comme un décompte officiel ou définitif.
Une mesure d’exposition répond à la question « qu’est-ce qui paraît accessible ? ». Une analyse de vulnérabilité vérifie ensuite le logiciel réellement exécuté, sa version, sa configuration et les conditions nécessaires à l’attaque. Confondre les deux peut déclencher une intervention d’urgence coûteuse là où une vérification technique de courte durée aurait suffi.
Que savait-on sur les deux vulnérabilités PHP critiques ?
Le PHP Security Team a annoncé le 20 octobre 2026 deux vulnérabilités critiques, chacune notée 9,2 sur 10 avec le référentiel CVSS v4.0. Les correctifs étaient programmés pour le 21 octobre à 14 h UTC, soit 16 h en France métropolitaine, mais les détails techniques avaient été volontairement réservés aux avis définitifs.
L’annonce préalable ne nommait pas les composants affectés, les branches vulnérables, les versions corrigées ou les conditions d’exploitation. Elle visait à permettre aux administrateurs de préparer une mise à jour rapide. Des publications ont évoqué les identifiants CVE-2026-109618 et CVE-2026-109619 ainsi qu’une exécution de code à distance sans authentification, mais ces éléments n’apparaissaient pas dans l’annonce initiale du projet PHP.
Patchstack indiquait le 21 octobre 2026 que des partenaires d’hébergement avaient signalé une exploitation active à partir de 7 h 34 UTC. Les sources examinées ne fournissaient cependant pas de confirmation technique indépendante ni le périmètre exact des versions concernées. Pour décider d’une action métier, un signal remonté par un acteur de la sécurité mérite attention, mais ne remplace pas l’avis officiel ou celui de l’hébergeur.
Les branches officiellement prises en charge le 21 octobre 2026 étaient PHP 8.2, 8.3, 8.4 et 8.5. Selon la documentation de PHP, la branche 8.2 devait recevoir des correctifs de sécurité jusqu’au 31 décembre 2026 ; les branches plus anciennes étaient arrivées en fin de vie. Les dernières versions de sécurité publiées avant l’alerte d’octobre étaient PHP 8.2.34, 8.3.35, 8.4.26 et 8.5.11, datées du 24 septembre 2026.
Que doit faire un abonné Freebox par prudence ?
Un abonné Freebox doit vérifier l’utilité de l’administration à distance, la désactiver lorsqu’elle ne sert pas, employer un mot de passe administrateur robuste et maintenir le micrologiciel de la box à jour. Ces mesures réduisent l’exposition générale en 2026, mais elles ne prouvent pas que les vulnérabilités PHP annoncées affectent Freebox OS.
La documentation de Free confirme que l’administration distante de Freebox OS peut être activée dans « Gestion des accès ». L’interface utilise une authentification par mot de passe et peut être rendue accessible au moyen d’une adresse IP ou d’un nom de domaine associé à un port configuré.
Les vérifications utiles sont limitées et concrètes :
- désactivez l’accès distant si vous n’administrez jamais la Freebox hors de votre domicile ou de vos locaux ;
- remplacez un mot de passe court, réutilisé ou partagé par un mot de passe administrateur unique ;
- installez les mises à jour du micrologiciel proposées par Free ;
- contrôlez les paramètres d’accès plutôt que de vous fier à la présence d’une adresse contenant « .php » ;
- attendez un avis officiel de Free avant d’attribuer un incident aux failles PHP d’octobre 2026.
Réinitialiser la box ou modifier toute la configuration réseau sans indice de compromission n’est pas la réponse proportionnée. Honnêtement, mieux vaut supprimer une exposition distante inutile que multiplier les manipulations susceptibles d’interrompre la connexion de l’entreprise. Pour aller plus loin, quelques outils gratuits de cybersécurité permettent aussi de structurer les contrôles de base sans remplacer un audit.
Comment vérifier un site ou une application qui utilise PHP ?
Un administrateur d’un service PHP doit inventorier les versions exécutées sur les serveurs web, les pools PHP-FPM, les conteneurs et les tâches en ligne de commande. Il doit ensuite repérer les services accessibles depuis Internet, appliquer la version corrigée officielle ou fournie par l’hébergeur, redémarrer les processus concernés et contrôler la version réellement active.
PHP-FPM est un gestionnaire de processus qui exécute PHP pour un serveur web tel que Nginx. Le conteneur, par exemple avec Docker, isole une application avec ses dépendances. Ces deux couches créent un risque fréquent : mettre à jour le paquet du serveur ne suffit pas si une ancienne image de conteneur ou un processus non redémarré continue de fonctionner.
Sur les projets que nous menons, nous voyons souvent plusieurs versions de PHP cohabiter : une pour le site public, une autre pour une tâche planifiée et parfois une troisième dans un ancien conteneur. L’inventaire doit donc porter sur les processus actifs, pas seulement sur la version affichée dans le panneau d’hébergement.
Le correctif peut provenir directement du projet PHP ou être intégré par un fournisseur comme OVHcloud, une distribution Linux ou une plateforme managée. Le bon réflexe consiste à suivre le canal du fournisseur qui maintient réellement le paquet. Une version dont le numéro semble ancien peut, dans certains cas, inclure un correctif rétroporté ; seul l’avis du fournisseur permet de le confirmer.
Après la mise à jour, vérifiez la version chargée par le serveur web et redémarrez les pools PHP-FPM, les conteneurs et les tâches persistantes concernés. Testez ensuite les parcours essentiels de l’application. Une protection périphérique comme Cloudflare peut filtrer certaines requêtes, mais elle ne remplace pas la correction du composant vulnérable, tout comme une protection contre les attaques DDoS ne corrige pas une faille applicative.
Comment décider sans céder à une alerte prématurée ?
La bonne décision consiste à séparer quatre niveaux : service visible, technologie confirmée, version vulnérable et exploitation techniquement possible. Pour les failles PHP d’octobre 2026, l’urgence concernait les administrateurs de services PHP avérés. Les abonnés Freebox devaient réduire les accès inutiles, sans considérer leur équipement comme compromis sur la seule base d’un scan.
Côté agence, le réflexe est de conserver une trace de la version avant et après correction, de la source du paquet et des tests réalisés. Cette discipline facilite l’arbitrage avec l’hébergeur, évite de déclarer trop vite l’incident clos et fournit des éléments exploitables si une anomalie apparaît ensuite.
Une mise à jour éditoriale et technique reste nécessaire après publication des avis définitifs du PHP Security Team. Elle doit consigner les identifiants CVE confirmés, les versions affectées et corrigées, les prérequis d’exploitation ainsi que les éventuels avis des fournisseurs. Sans ces informations, attribuer un risque précis à une Freebox ou à un site donné serait spéculatif.
Cadrer l’exposition, l’inventaire logiciel et la procédure de correction avant une alerte évite la plupart des décisions précipitées. Un regard extérieur peut surtout aider à distinguer un signal médiatique d’un risque démontré, puis à concentrer le budget et le temps d’arrêt sur les services réellement concernés.
FAQ sur les failles PHP et les Freebox
Une adresse qui se termine par .php prouve-t-elle que le serveur utilise PHP ?
Une adresse se terminant par « .php » ne prouve pas qu’un interpréteur PHP fonctionne sur le serveur. Le nom peut être conservé pour des raisons de compatibilité ou être traité par un autre logiciel.
Le score CVSS 9,2 signifie-t-il qu’une attaque a déjà réussi ?
Un score CVSS v4.0 de 9,2 indique une sévérité potentielle critique, pas une compromission constatée. La présence du composant touché, sa version, sa configuration et les conditions d’exploitation doivent encore être vérifiées.
Faut-il désactiver l’administration à distance de Freebox OS ?
L’administration à distance de Freebox OS devrait être désactivée lorsqu’elle n’est pas utilisée. Lorsqu’elle est nécessaire, un mot de passe unique et robuste ainsi qu’un micrologiciel à jour réduisent l’exposition générale.
Comment savoir quelle version de PHP fonctionne réellement sur un site ?
La version PHP réelle doit être contrôlée dans le processus qui sert le site, le pool PHP-FPM ou le conteneur actif. La version affichée par un panneau d’hébergement ou une ligne de commande peut différer de celle exécutée par l’application.