Même si les dommages ne sont pas confirmés, on ne peut pas être tranquille : arrêt des sites en raison d'une vulnérabilité PHP, que se passe-t-il actuellement ?

Un site que vous utilisez habituellement devient soudainement inaccessible. Cependant, si la raison n'est pas une destruction due à une cyberattaque, mais plutôt une suspension temporaire pour se protéger contre une attaque, comment réagiriez-vous ?

Une vulnérabilité critique dans le langage de programmation PHP, qui soutient les sites web et les applications web, a été révélée, et en Allemagne, des institutions administratives ont préventivement suspendu leurs sites.

Selon un article de l'AFP publié le 22 octobre par BUSINESS-PANORAMA, l'Office fédéral de la sécurité des technologies de l'information (BSI) en Allemagne a expliqué qu'à ce moment-là, aucun cas d'exploitation de cette vulnérabilité n'avait été confirmé. Cependant, ils n'ont pas exclu la possibilité que des attaques aient réussi.

Ce qui est important à retenir en lisant cette nouvelle, c'est que « ne pas avoir confirmé de dommages » n'est pas équivalent à « sécurité confirmée ».

L'annonce du BSI n'est pas une déclaration de fin de crise

Selon l'article original, le BSI a averti de la vulnérabilité de PHP le 21 octobre après-midi et a annoncé qu'une mise à jour de sécurité était prévue le même jour à 16 heures.

Ce qui était redouté, c'était la possibilité que des attaques se propagent après la publication du contenu de la mise à jour. Si la localisation du problème devenait claire grâce à la correction, les attaquants pourraient analyser ces informations et cibler les systèmes non corrigés. L'article exprime également des inquiétudes quant à la facilité avec laquelle cette analyse pourrait être réalisée par l'IA.

Le lendemain, le 22 octobre, le BSI a expliqué que la plupart des sites des agences fédérales, qui avaient été arrêtés à titre préventif, avaient été rétablis. Ils ont suggéré que l'absence de rapports de systèmes compromis pourrait être due au fait que de nombreux opérateurs avaient suivi les recommandations et effectué les mises à jour.

Cependant, cela est basé sur les informations disponibles. Cela ne signifie pas qu'une enquête a été menée sur tous les sites et qu'il n'y a pas eu d'intrusion.

La reprise des sites est une bonne nouvelle pour les utilisateurs, mais il est trop tôt pour conclure que l'ensemble du problème est résolu uniquement pour cette raison.

Le problème réside dans la « fondation » des sites web

Cette fois, ce que PHP a corrigé, ce sont deux vulnérabilités critiques appelées « PHP2Shell ». Les numéros d'identification sont CVE-2026-109618 et CVE-2026-109619. L'évaluation CVSS v4.0 de leur gravité est de 9,2, les classant comme « Critiques ».

La PHP Foundation a annoncé le 21 octobre qu'elle avait corrigé un problème qui permettait à un attaquant non authentifié d'exécuter du code sur un serveur exécutant PHP, sous certaines conditions.

Pour les utilisateurs ordinaires, PHP est quelque chose dont ils ne sont généralement pas conscients. Ce n'est pas le design de l'écran ou l'article lui-même, mais ce qui gère le traitement en arrière-plan.

Par conséquent, lorsque l'on considère la réponse actuelle, il ne suffit pas de se concentrer uniquement sur l'apparence du site ou sur l'écran de gestion. Il est nécessaire de vérifier l'état de la correction de la base qui fait fonctionner l'application.

Les versions corrigées publiées par la PHP Foundation sont PHP 8.2.35, 8.3.36, 8.4.27, 8.5.12. Les opérateurs doivent vérifier l'état de l'application des corrections, y compris les instructions fournies par les prestataires de leur environnement.

Ne pas confondre « tentative d'attaque » et « succès de l'intrusion »

En plus de l'article original concernant le BSI, il est important de noter le rapport d'observation d'AWS.

AWS a annoncé qu'avec son système « MadPot » pour observer les attaques, il avait confirmé une tentative d'exploitation de PHP2Shell remontant au 17 octobre. Cela correspond à un moment antérieur à la divulgation des détails de la vulnérabilité.

D'un autre côté, AWS a déclaré qu'il n'était pas clair si les tentatives observées avaient réussi sur des systèmes réels.

En d'autres termes, le rapport du BSI selon lequel « aucun cas d'exploitation n'a été confirmé » et le rapport d'AWS selon lequel « une tentative d'attaque a été observée » concernent des sujets et des contenus de vérification différents. On ne peut pas conclure qu'il n'y a pas eu d'attaque ou qu'un dommage d'intrusion à grande échelle a été confirmé en ne considérant qu'un seul des deux.

En tant qu'utilisateur ou opérateur, il est nécessaire de lire séparément l'existence de la vulnérabilité, l'observation de l'attaque, le succès de l'intrusion et la confirmation de la fuite d'informations.

Sur les réseaux sociaux, des voix saluent la rapidité de la correction

Sur les réseaux sociaux et dans les communautés en ligne, on trouve non seulement un sentiment de crise, mais aussi des opinions sur la manière dont les nouvelles sont perçues.

Dans le post « Has PHP2Shell borne fruit? » de la communauté PHP sur Reddit, des opinions ont été exprimées, saluant la rapidité de la correction et la réponse des principales distributions Linux, tout en mentionnant des articles alarmistes et des critiques envers PHP.

Cela montre une perception qui souhaite que l'on regarde aussi la réponse des développeurs et des distributeurs, indépendamment de la gravité de la vulnérabilité. Cependant, l'évaluation des dommages par le posteur ne signifie pas que cela reflète la sécurité mondiale.

D'autre part, dans un post Reddit concernant le service d'alias de messagerie addy.io, il a été partagé que le système web avait été temporairement suspendu en réponse à PHP2Shell. Il a été expliqué que la livraison des e-mails se poursuivait, et une annonce a été faite indiquant que le système avait été rétabli après l'application des corrections.

Ne pas se contenter de dire simplement « le service est indisponible », mais communiquer ce qui est arrêté, ce qui est disponible et quand cela a été rétabli. Ce type de partage d'informations peut être utile pour réduire l'anxiété des utilisateurs.

Il convient de noter que ce qui est présenté ici est un post individuel vérifié et ne représente pas l'opinion majoritaire ou un sondage d'opinion sur l'ensemble des réseaux sociaux.

La décision d'arrêter un site nécessite également des explications

Une suspension préventive peut causer des désagréments aux utilisateurs. Si cela entraîne des impacts tels que l'impossibilité de faire des demandes, de poursuivre des procédures ou d'acheter des produits, cela peut également peser sur l'opérateur.

Néanmoins, limiter l'accès externe jusqu'à ce que la correction soit effectuée a pour but de réduire l'exposition aux attaques. CERT-EU conseille également de considérer l'isolement des applications publiées sur Internet du réseau public si une correction immédiate n'est pas possible.

C'est pourquoi il est difficile de juger de la qualité de l'exploitation uniquement sur la base de la question de savoir si un arrêt a eu lieu.

Ce qui est plutôt en question, c'est si la raison de l'arrêt a été expliquée, si les fonctions affectées ont été clairement indiquées, et où les utilisateurs peuvent vérifier la prochaine annonce.

Un site qui disparaît sans explication et un site qui communique des mesures pour protéger ses utilisateurs seront perçus différemment, même s'ils sont tous deux arrêtés.

Pour les opérateurs japonais, ce n'est pas seulement une « nouvelle étrangère »

Le problème PHP ne concerne pas seulement les sites en langue allemande. Les opérateurs japonais doivent également vérifier si leur environnement utilise la même technologie.

Dans ce cas, le premier défi pourrait être de clarifier qui gère le site de l'entreprise, plutôt que de modifier des paramètres techniques.

Est-ce que c'est une société de production qui s'en charge ? Est-ce que c'est l'entreprise de serveurs loués qui met à jour la base ? Ou bien est-ce qu'un responsable interne doit s'en occuper ?

Les points à vérifier peuvent être organisés comme suit :

• L'environnement de fonctionnement du site utilise-t-il PHP ?
• Les corrections pour la vulnérabilité actuelle ont-elles été appliquées ?
• Les responsables de la mise à jour et la méthode de vérification de l'achèvement de la réponse ont-ils été déterminés ?
• Si une correction immédiate n'est pas possible, qui prendra la décision de limiter la publication ?

Il y a une grande différence entre « l'entreprise sous-traitante devrait s'en occuper » et « la confirmation que la réponse a été effectuée ».

De plus, CERT-EU indique que pour les séries antérieures à PHP 8.1, dont le support est terminé, aucune mise à jour ne sera fournie par le projet PHP. Si vous continuez à utiliser un ancien environnement, vous devez vérifier si des corrections ont été apportées par le fournisseur de cet environnement et si une migration est nécessaire.

Même avec des mesures de défense, cela ne remplace pas la mise à jour

Il peut être tentant de penser que tout va bien parce que des mécanismes de défense contre les attaques ont été mis en place.

Cependant, AWS précise que pour le problème actuel, les mesures prises par le WAF ne sont qu'un complément pour réduire la portée de l'exposition au danger et ne remplacent pas la mise à jour de PHP.

Ce qui est important, c'est moins le fait d'utiliser un produit de défense que de savoir dans quelle mesure cette mesure couvre le problème actuel.

L'article original mentionne également que le BSI a appelé les utilisateurs ordinaires à ne pas laisser leurs routeurs accessibles depuis l'extérieur, et à être prudents lors des téléchargements ou de la fourniture d'informations confidentielles.

Cela ne signifie pas que tous les terminaux ou routeurs des utilisateurs sont directement affectés par la vulnérabilité actuelle. Les mesures prises par les opérateurs et la prudence quotidienne des utilisateurs doivent être perçues séparément.

Il y a un travail qui soutient le fait que « rien ne s'est passé »

Après un grand avertissement, si aucun dommage notable n'est rapporté, certaines personnes pourraient penser que « c'était exagéré ».

Cependant, la raison pour laquelle les dommages ne sont pas visibles pourrait être due à des mises à jour précoces ou à des arrêts préventifs, ou il pourrait y avoir des dommages qui n'ont pas encore été identifiés. On ne peut pas conclure l'un ou l'autre uniquement sur la base des informations actuelles.

Ce que montre la vulnérabilité PHP actuelle, c'est que la responsabilité de l'opérateur ne se limite pas à maintenir le site en ligne. Arrêter lorsque c'est nécessaire, corriger, vérifier l'état, et expliquer aux utilisateurs. Cette série de réponses fait également partie du travail de soutien du service.

L'annonce de « dommages non confirmés » ne doit pas être une raison pour arrêter de répondre. Ce n'est qu'après avoir vérifié l'état de votre propre environnement que la lecture des nouvelles peut se traduire par une préparation réelle.

Sources

1. BUSINESS-PANORAMA/AFP (22 octobre 2026)
   Le BSI n'a pas confirmé de cas d'exploitation, n'a pas exclu la possibilité d'intrusion, l'état de rétablissement des sites administratifs, et les raisons de l'appel à la prudence pour les utilisateurs ordinaires.
   https://business-panorama.de/news.php?newsid=6715602

2. PHP Foundation « Today's PHP Security Release, and How We're Strengthening PHP Security »
   Publication de la version corrigée le 21 octobre et explication officielle des dangers posés par la vulnérabilité.
   https://thephp.foundation/blog/2026/10/21/todays-php-security-release-and-how-were-strengthening-php-security/thephp.foundation

3. CERT-EU « Critical Vulnerabilities in PHP »
   Numéros CVE, gravité, environnements affectés, séries dont le support est terminé, conseils officiels sur les corrections ou l'isolement.
   https://www.cert.europa.eu/publications/security-advisories/2026-018Critical Vulnerabilities in PHP

4. AWS Security Blog : Rapport d'observation de PHP2Shell par MadPot
   Tentatives d'attaque avant la divulgation publique et explication de l'incertitude quant à leur succès dans des environnements réels. Distinction entre « observation de l'attaque » et « confirmation des dommages ».
   https://aws.amazon.com/blogs/security/amazon-threat-intelligence-identifies-php2shell-exploitation-prior-to-public-disclosure-in-madpot/aws.amazon.com

5. AWS Security Blog : Mesures d'atténuation du WAF contre PHP2Shell
   Positionnement du WAF et explication officielle de la nécessité de mettre à jour PHP.
   https://aws.amazon.com/blogs/security/using-aws-waf-to-apply-mitigations-for-php2shell-rce-vulnerabilities-cve-2026-109618-and-cve-2026-109619/##HTML_TAG_207