En bref : le BSI a déclenché le niveau d'alerte 3 (orange) pour PHP2Shell. La recommandation est sans équivoque : mettre PHP à jour immédiatement et, si ce n'est pas possible tout de suite, déconnecter temporairement du réseau les serveurs web concernés. Le BSI s'attendait à une exploitation rapide et massive ; des attaques réussies à grande échelle n'étaient d'abord pas confirmées.
L'alerte du BSI sur PHP en bref
Le Bundesamt für Sicherheit in der Informationstechnik (BSI, office fédéral allemand de la sécurité des technologies de l'information) est l'autorité spécialisée centrale pour la cybersécurité en Allemagne. Il a publié pour PHP2Shell une alerte de niveau 3 (orange). Elle fait suite à deux failles critiques dans PHP lui-même : CVE-2026-109618 et CVE-2026-109619, toutes deux évaluées à CVSS v4.0 9.2. Elles permettent à des attaquants d'exécuter du code malveillant sur le serveur sans authentification.
Les principaux messages de l'alerte peuvent se résumer ainsi :
| Message | Signification pour les exploitants |
|---|---|
| Niveau d'alerte 3 / orange | situation sérieuse, action nécessaire |
| Mise à jour immédiate recommandée | installer les versions corrigées de PHP |
| Sinon, mise hors réseau temporaire | subordonner l'accessibilité à la protection |
| Exploitation rapide et massive attendue | ne pas attendre les premiers signalements de dommages |
| Attaques réussies à grande échelle d'abord non confirmées | pas de raison de lever l'alerte |
Vous trouverez la version actuelle sur le site du BSI.
Ce que « mettre à jour immédiatement » signifie concrètement
Le projet PHP a publié les versions corrigées le 21 octobre 2026 à 14 h 00 UTC (16 h, heure allemande) : PHP 8.5.12, 8.4.27, 8.3.36 et 8.2.35. Pour PHP 8.1 et antérieur, il n'existe plus de mises à jour officielles, seulement des backports minimaux du code source pour 7.4, 8.0 et 8.1.
Une mise à jour n'est effective que lorsque tous les processus PHP ont été redémarrés. De nouveaux fichiers seuls ne suffisent pas tant que d'anciens workers tournent en mémoire. De plus : les distributions et les hébergeurs appliquent parfois les corrections sous forme de backport. Plesk continue alors d'afficher 8.2.34 alors que le serveur est corrigé. L'état des paquets et la confirmation du fournisseur sont déterminants. Et une mise à jour du CMS, par exemple de WordPress, ne comble pas la faille PHP.
Si une mise à jour n'est pas possible immédiatement
Dans ce cas, le BSI recommande de déconnecter temporairement les serveurs web du réseau. C'est une mesure dure, mais claire. Pour de nombreuses entreprises, une interruption planifiée de quelques heures est moins préjudiciable qu'une intrusion avec fuite de données.
php.net indique en outre des mesures transitoires qui réduisent le risque, mais n'offrent expressément pas de protection complète. Elles comprennent session.upload_progress.enabled=0 dans la configuration du serveur, des valeurs limitées de post_max_size, des limites de mémoire via les conteneurs ou les cgroups et, sur PHP 8.5, fatal_error_backtraces=0, chaque fois suivis d'un redémarrage de tous les workers. Les détails figurent sous Mesures immédiates sans correctif.
Si un serveur web accessible publiquement tourne encore avec un PHP non corrigé et sans mesures transitoires, la recommandation du BSI implique : déconnecter le serveur du réseau jusqu'à ce que la mise à jour soit installée et que tous les processus soient redémarrés.
Mise en perspective de la situation
Le BSI n'est pas seul à porter cette appréciation. Cloudflare a signalé des tentatives d'attaque observées et déployé des règles de protection, mais avertit que des règles fondées sur les seules données de la requête ne suffisent pas. Palo Alto Networks (Unit 42) a dénombré plus de 22,6 millions d'instances exposées et potentiellement vulnérables. Selon des articles de presse, une première tentative d'attaque a déjà été observée le 17 octobre 2026, donc avant la publication des correctifs.
Pour les exploitants, il en résulte une évaluation sobre : qui n'a pas corrigé jusqu'à aujourd'hui devrait non seulement corriger, mais aussi vérifier si quelque chose s'est déjà produit. Un correctif ne supprime pas les logiciels malveillants introduits. Il n'existe pas d'indicateurs de compromission (IoC) publiés et confirmés ; la détection repose sur l'analyse comportementale. La presse spécialisée conseille de conserver les journaux du serveur à partir du 20 octobre 2026. Des indications pour la recherche figurent sous Suis-je déjà compromis ?.
Ce que la recommandation signifie pour les responsables
Une alerte du BSI n'est pas une loi. C'est toutefois l'appréciation de l'autorité spécialisée compétente, qui pourra jouer un rôle dans l'évaluation ultérieure de décisions, par exemple par des assureurs ou des auditeurs. Les directions devraient donc documenter quand elles ont pris connaissance de l'alerte, comment elles évaluent leurs propres systèmes et quelles mesures elles ont prises. Des indications générales figurent sous Responsabilité de la direction ; il ne s'agit pas d'un conseil juridique.
En pratique, il est recommandé de ne pas lire l'alerte une seule fois. Le BSI met à jour ses avis lorsque la situation change, par exemple en cas de nouveaux éléments sur l'exploitation ou sur d'autres failles. Depuis le 23 octobre 2026, il existe en outre un avis de php.net sur CVE-2026-115560, qui ne concerne que des configurations inhabituelles et est lui aussi atténué par session.upload_progress.enabled=0. Désignez une personne qui consulte quotidiennement le BSI et php.net jusqu'à la clôture de la situation et transmet les changements à la technique et à la direction. Il n'y a ainsi pas de décalage de connaissance entre ceux qui décident et ceux qui mettent en œuvre.
Comment PHP SOS aide-t-il concrètement ?
- Nous confrontons vos serveurs web à la recommandation du BSI : version, état des paquets, redémarrage, accessibilité.
- Dans le cadre de l'assistance immédiate PHP2Shell, nous corrigeons, redémarrons tous les processus et fournissons un justificatif.
- Là où une mise à jour n'est pas possible immédiatement, nous mettons en place des mesures transitoires et fournissons au besoin une page de remplacement statique.
- Nous sauvegardons les journaux et recherchons des traces, afin que vous puissiez évaluer la situation de façon fiable après le correctif.
Questions fréquentes
Que signifie le niveau d'alerte 3 (orange) du BSI ?
La couleur décrit une menace élevée et sérieuse nécessitant une action. Pour PHP2Shell, le BSI (office fédéral allemand de la sécurité des technologies de l'information) le justifie par la criticité des failles et par leur exploitation rapide attendue. La définition exacte des niveaux figure sur le site du BSI.
Dois-je suivre la recommandation du BSI ?
Une alerte du BSI est une recommandation, pas une loi. C'est toutefois une appréciation de poids de l'autorité spécialisée compétente, sur laquelle assureurs, auditeurs et tribunaux peuvent s'appuyer. Qui s'en écarte devrait documenter ses raisons. Ceci ne constitue pas un conseil juridique.
Y a-t-il déjà eu, selon le BSI, des attaques réussies ?
Selon le BSI, des attaques réussies à grande échelle n'étaient d'abord pas connues. Le BSI s'attendait toutefois à une exploitation rapide et massive. D'autres organismes ont déjà signalé des tentatives d'attaque.
Où trouver la version actuelle de l'alerte ?
Sur le site du BSI, parmi les alertes de sécurité actuelles. La situation peut évoluer ; consultez régulièrement l'état le plus récent à cet endroit et sur php.net.