La faille PHP met les administrations face au risque d’interruption

Fermer temporairement un site public pour éviter une intrusion : la vulnérabilité de PHP place les administrations devant un arbitrage de continuité du service. Plusieurs organismes européens ont suspendu leur présence en ligne après la divulgation d’une faille dans ce langage de programmation utilisé pour faire fonctionner des sites web. La protection informatique produit ainsi un effet immédiatement visible pour les usagers, même en l’absence de compromission établie.

Cloudflare, qui fournit notamment des services de protection contre les attaques, fait état de millions de tentatives d’exploitation. Amazon Web Services (AWS) décrit également une exploitation en circulation. Ces alertes ne recouvrent pourtant pas exactement les premiers constats des autorités allemandes et néerlandaises : celles-ci rapportent des attaques ou une menace, mais pas de succès identifié dans leur périmètre d’observation initial.

Le nombre de requêtes hostiles ne mesure pas le nombre de systèmes compromis. Cette distinction détermine la réponse opérationnelle. Un gestionnaire doit réduire son exposition sans prendre chaque tentative automatisée pour la preuve d’une intrusion, ni interpréter l’absence de succès détecté comme une garantie de sécurité.

La vulnérabilité de PHP confronte des observations différentes

Matthew Prince, directeur général de Cloudflare, décrit une accélération des tentatives autour de l’annonce publique. Il indique que son entreprise en avait déjà observé avant cette divulgation. Ce constat constitue un signal d’alerte, mais ne permet pas, à lui seul, d’établir comment les attaquants ont obtenu les informations nécessaires, ni combien ont atteint leur objectif.

La position de Cloudflare dans le trafic web lui donne une capacité importante d’observation. Elle ne transforme pas pour autant ses données en bilan exhaustif des intrusions. Des requêtes peuvent être bloquées, viser des systèmes non concernés ou échouer parce que les conditions techniques nécessaires ne sont pas réunies.

Le vice-président de l’Office fédéral de la sécurité des technologies de l’information allemand (BSI), Thomas Caspers, indique que son agence a observé des attaques sans constater, dans un premier temps, d’exploitation réussie. Selon lui, le passage à une attaque efficace paraît plus compliqué qu’anticipé lors de la préparation du correctif. Il ne présente toutefois pas d’explication définitive à cette difficulté.

Aux Pays-Bas, le responsable de l’agence nationale de cybersécurité, Matthijs van Amelsfort, signale également l’absence initiale d’indication d’un usage malveillant effectif. Ce constat reste circonscrit aux informations alors disponibles. Il ne contredit pas nécessairement les observations des prestataires privés : leurs réseaux, leurs clients et leurs moyens de détection ne sont pas identiques.

La mise hors ligne déplace le coût vers l’usager

En France, les sites du ministère de la Justice et de la CNIL ont affiché des messages de maintenance dans la séquence suivant l’alerte. Ces messages ne constituent pas une preuve d’intrusion. Ils rendent en revanche visible le coût d’une réponse préventive : l’accès à l’information publique peut être interrompu avant même qu’un dommage informatique soit établi.

La vulnérabilité de PHP met ainsi en évidence une dépendance qui dépasse le choix d’un langage. La continuité d’un service repose sur une chaîne associant développement, hébergement, maintenance et sécurité. Disposer d’un correctif ne suffit pas : encore faut-il identifier les installations concernées, organiser son déploiement et vérifier que la remise en service ne laisse pas subsister d’exposition.

L’agence néerlandaise de cybersécurité a elle-même retiré temporairement son site avant de le rétablir. L’épisode montre que les organismes chargés de protéger les autres administrations doivent aussi gérer leurs propres dépendances techniques. Une mission de sécurité ne dispense pas des contraintes ordinaires d’exploitation d’un service web.

Le correctif ouvre une course de déploiement

La divulgation change le rapport de force informationnel. Les responsables disposent d’éléments pour corriger leurs systèmes ; les attaquants peuvent également concentrer leurs recherches sur les installations qui restent exposées. L’avantage se joue alors dans le délai entre l’alerte, l’identification du périmètre concerné et l’application effective des mesures de protection.

Pour la vulnérabilité de PHP, les premiers retours européens invitent à ne confondre ni vitesse des tentatives et efficacité des attaques, ni difficulté initiale et protection durable. Une exploitation qui exige davantage de préparation peut laisser du temps aux défenseurs. Elle ne supprime pas la nécessité de corriger.

L’enjeu pour les administrations françaises est donc aussi organisationnel. La maîtrise du service dépend de leur capacité à savoir quels composants fonctionnent sur leurs sites, qui peut intervenir et dans quelles conditions l’accès peut être rétabli. Le bilan utile ne sera pas seulement celui des attaques détectées, mais celui des systèmes corrigés et des services remis à disposition sans exposition résiduelle identifiée.