PHP2Shell : deux failles critiques dans php provoquent une onde de choc sur le web mondial
Le 21 octobre 2026, de nombreux sites gouvernementaux, services publics et plateformes numériques ont été temporairement mis hors ligne pour se protéger de deux vulnérabilités majeures découvertes dans PHP. Derrière cette mobilisation internationale se dessine un événement de cybersécurité particulièrement révélateur : l’intelligence artificielle accélère la découverte de failles longtemps restées invisibles, tandis que la dépendance du Web à quelques technologies fondamentales devient un enjeu stratégique.
Mis à jour le 22 octobre 2026 — Point de situation au matin.
Le mercredi 21 octobre 2026 restera probablement comme une journée particulière dans l’histoire de la cybersécurité du Web. En quelques heures, des administrations européennes, des établissements de santé, des entreprises et des fournisseurs d’hébergement ont pris des mesures exceptionnelles pour protéger leurs infrastructures.
À l’origine de cette mobilisation : deux vulnérabilités critiques dans PHP, l’un des langages de programmation les plus utilisés pour faire fonctionner les sites Internet.
Baptisées collectivement PHP2Shell, ces failles permettent, dans certaines configurations, à un attaquant non authentifié d’exécuter du code à distance sur un serveur vulnérable. Leur gravité, leur ancienneté et surtout l’étendue des systèmes potentiellement exposés ont déclenché une réponse internationale inhabituelle.
L’épisode prend une dimension supplémentaire lorsqu’on découvre le rôle joué par l’intelligence artificielle dans l’identification et l’exploitation expérimentale de ces vulnérabilités.
Et comme pour souligner la dépendance croissante de nos sociétés aux infrastructures numériques, deux autres incidents majeurs ont marqué les mêmes journées : une panne du réseau mobile d’Orange en France et une défaillance électrique affectant Google Cloud à Londres, avec des conséquences jusque dans les services bancaires britanniques.
Trois événements distincts, sans lien connu entre eux, mais qui interrogent collectivement la résilience de notre écosystème numérique.
PHP : une technologie historique toujours au cœur du Web
Créé en 1995, PHP est l’un des langages qui ont accompagné la démocratisation d’Internet.
À l’origine conçu pour faciliter la création de pages web dynamiques, il s’est progressivement imposé comme un composant majeur des architectures applicatives.
PHP fonctionne principalement côté serveur. Lorsqu’un internaute consulte une page, remplit un formulaire ou réalise une opération sur une boutique en ligne, le serveur peut exécuter du code PHP pour interroger une base de données, gérer une session ou produire le contenu envoyé au navigateur.
Cette technologie est au cœur de nombreuses plateformes populaires, notamment WordPress, Drupal, Joomla, Magento et MediaWiki, le logiciel utilisé par Wikipédia.
Son importance est considérable.
Selon les statistiques de W3Techs du 22 octobre 2026, PHP est utilisé par 69,3 % des sites web dont le langage de programmation côté serveur est identifié.
Cette précision méthodologique est importante : cela ne signifie pas que 69,3 % de tous les sites Internet sont vulnérables. Le risque dépend de la version de PHP, des correctifs installés et de l’environnement d’exécution.
Il n’en demeure pas moins que PHP constitue un socle majeur de l’économie numérique.
Un rôle central dans les architectures digitales et les MarTech
Pour les professionnels du marketing et du digital, PHP est loin d’être une technologie secondaire.
Il intervient dans de nombreux sites de commerce électronique, espaces clients, portails de marques, plateformes de contenus et interfaces intégrées aux stacks MarTech.
Un site WordPress connecté à un CRM, une boutique Magento reliée à une CDP ou un portail client alimentant un système de marketing automation peuvent tous dépendre d’un environnement PHP.
Une compromission du serveur ne menace donc pas uniquement l’affichage d’un site : elle peut potentiellement exposer des données clients, des identifiants techniques, des informations commerciales et des connexions aux systèmes métiers.
C’est ce qui rend PHP2Shell particulièrement préoccupant.
PHP2Shell : deux vulnérabilités critiques au cœur du langage
Les failles identifiées sous les références CVE-2026-109618 et CVE-2026-109619 concernent le moteur d’exécution de PHP lui-même.
Elles ne proviennent pas d’un plugin WordPress défectueux, d’un thème mal développé ou d’un CMS insuffisamment sécurisé.
Elles résident dans la manière dont PHP gère certaines erreurs et les ressources mémoire utilisées pendant l’exécution des requêtes.
Les deux vulnérabilités ont reçu un score de 9,2 sur 10 selon CVSS v4.0, ce qui les classe au niveau critique.
CVE-2026-109618 : corruption mémoire lors d’un manque de ressources
Cette première vulnérabilité concerne le traitement des situations où PHP atteint une limite de mémoire (Out of Memoryou OOM).
Normalement, lorsqu’une opération dépasse les ressources autorisées, PHP interrompt son exécution et procède à un nettoyage interne.
Or, certaines interruptions peuvent survenir alors que des structures mémoire ne sont pas encore entièrement initialisées.
Dans ces circonstances, le processus de nettoyage peut manipuler des données invalides et provoquer une corruption mémoire.
Des chercheurs ont démontré qu’un attaquant pouvait exploiter ce comportement pour obtenir une exécution de code à distance (Remote Code Execution ou RCE).
CVE-2026-109619 : réutilisation d’une mémoire déjà libérée
La deuxième vulnérabilité repose sur une autre erreur de gestion mémoire, généralement désignée par le terme use-after-free.
Lorsqu’une requête s’achève anormalement, PHP peut conserver une référence vers une zone mémoire qui a pourtant été libérée.
Une requête suivante, traitée par le même processus, peut alors réutiliser cette référence devenue invalide.
Dans certaines conditions, ce comportement peut permettre de lire des informations présentes en mémoire, de provoquer un plantage ou d’exécuter du code malveillant.
Pourquoi ces failles sont-elles particulièrement dangereuses ?
Leur caractère critique tient à trois éléments.
D’abord, elles peuvent être exploitées sans authentification préalable : l’attaquant n’a pas nécessairement besoin de disposer d’un compte sur l’application ciblée.
Ensuite, elles se situent dans des mécanismes fondamentaux du moteur PHP, indépendamment de la qualité du code développé par l’éditeur du site.
Enfin, elles concernent plusieurs modes de déploiement, notamment Apache avec mod_php, PHP-FPM, php-cgi, FrankenPHP et LiteSpeed.
L’équipe PHP considère les installations Apache utilisant mod_php comme particulièrement exposées. Une exploitation a été démontrée avec une requête non authentifiée, avant même l’exécution du code applicatif.
Le surnom PHP2Shell fait naturellement écho à Log4Shell, la vulnérabilité majeure de l’écosystème Java révélée en décembre 2021. Les mécanismes techniques sont différents, mais les deux incidents illustrent un même risque : celui d’une faille profonde dans une technologie largement partagée par des milliers d’applications.
Une découverte qui remonte à plusieurs années, accélérée par l’intelligence artificielle
L’un des aspects les plus intéressants de PHP2Shell concerne l’histoire de sa découverte.
Contrairement à ce que l’on pourrait imaginer, les premiers indices ne datent pas d’octobre 2026.
Dès 2024, des signaux techniques avaient été identifiés
En 2024, la PHP Foundation organise un audit externe de sécurité réalisé par Quarkslab, avec le soutien de l’Open Source Technology Improvement Fund (OSTIF) et un financement de la Sovereign Tech Agency.
À la suite de cet audit, un développeur travaillant sur le cœur de PHP identifie les premiers signes d’un problème lié à la gestion des erreurs d’allocation mémoire.
La possibilité d’une exploitation est envisagée, sans qu’un scénario concret d’exécution de code à distance ait alors été démontré.
Les difficultés sont importantes : corriger ce comportement nécessite d’intervenir dans des composants fondamentaux de PHP, avec des risques de compatibilité, de performance et de régression pour les extensions existantes.
La PHP Foundation reconnaîtra ensuite que des contraintes organisationnelles et un manque de ressources ont contribué à retarder la résolution du problème.
Août 2026 : l’IA transforme un problème théorique en vulnérabilité démontrée
La situation évolue durant l’été 2026.
Dans le cadre de l’initiative Patch the Planet, soutenue par OpenAI, la société de recherche en sécurité Calif commence un nouvel audit de PHP le 30 juillet.
Le 11 août, le chercheur Ryan A. signale une possibilité d’exécution de code à distance reposant sur le problème de gestion mémoire déjà identifié.
OpenAI rapporte indépendamment la même cause fondamentale le même jour.
Quelques jours plus tard, Wiz Research découvre également des vulnérabilités critiques et parvient à démontrer leur exploitation contre des applications reposant sur Drupal et WordPress. Wiz transmet ses conclusions à l’équipe PHP le 24 août.
Ces recherches mobilisent des outils d’intelligence artificielle avancés, notamment GPT-5.6 Sol, Gemini 4 Argon et des systèmes spécialisés d’analyse de sécurité.
Selon Wiz, l’utilisation de ces modèles a considérablement accéléré l’identification des chaînes d’exploitation.
Il faut cependant éviter une interprétation excessive : l’IA n’a pas découvert seule un problème totalement inconnu avant 2026. Des chercheurs humains avaient déjà identifié une partie de la faiblesse. L’apport décisif des systèmes d’IA a été de faciliter l’analyse, de construire des scénarios d’exploitation et d’en démontrer l’impact réel.
L’épisode marque néanmoins une évolution majeure : des vulnérabilités présentes depuis plus de dix ans dans des logiciels largement audités peuvent désormais être redécouvertes et exploitées expérimentalement beaucoup plus rapidement.
20 octobre : une fuite précipite le calendrier de divulgation
La divulgation publique des vulnérabilités devait initialement intervenir le 22 octobre 2026.
Un calendrier coordonné avait été organisé afin que les développeurs PHP, les distributions Linux, les hébergeurs et les fournisseurs de sécurité disposent de suffisamment de temps pour préparer les mises à jour.
Mais le 20 octobre, ce dispositif est perturbé.
Vers 15 heures UTC, soit 17 heures à Paris, les identifiants des deux vulnérabilités commencent à circuler sur des forums et les réseaux sociaux.
Les premières informations annoncent une gravité maximale de 10/10 et une date de publication qui ne correspondent pas aux éléments officiellement retenus.
À ce stade, selon la PHP Foundation, les détails techniques des failles n’ont pas encore été divulgués.
L’équipe PHP décide néanmoins d’avancer son annonce et sa publication.
Vers 19 h 30 UTC, elle annonce que les correctifs seront disponibles le 21 octobre à 14 heures UTC, soit 16 heures à Paris, un jour plus tôt que prévu.
Une vidéo publiée par erreur aggrave la situation
Peu après cette préannonce, Calif publie accidentellement une vidéo montrant une preuve de concept exploitant les vulnérabilités.
La vidéo est rapidement supprimée, mais des copies commencent à circuler.
Cette fuite apporte des éléments techniques supplémentaires et contribue à accélérer la production de nouvelles preuves de concept.
Le 21 octobre à 7 h 41 UTC, un autre événement intervient : selon la PHP Foundation, le fournisseur Chainguard publie des images logicielles intégrant déjà les correctifs, avant la levée de l’embargo.
Cette décision permet à certains utilisateurs de disposer plus tôt d’une version corrigée, mais elle ouvre également la possibilité d’analyser les différences entre les versions vulnérables et corrigées.
C’est toute la difficulté de la divulgation coordonnée : prévenir suffisamment tôt pour permettre aux défenseurs de se préparer, sans offrir trop rapidement aux attaquants les informations nécessaires à l’exploitation.
La fuite a transformé une opération préparée depuis plusieurs semaines en véritable course contre la montre.
Cloudflare, hébergeurs et éditeurs : les premières protections sont déployées
Avant même la publication officielle des correctifs, plusieurs acteurs de l’infrastructure Internet ont commencé à déployer des mesures de protection.
Cloudflare : des protections activées avant la divulgation publique
Cloudflare a joué un rôle important dans cette première phase de réponse.
L’entreprise indique avoir travaillé depuis le début du mois d’octobre sur des mécanismes de protection destinés à ses clients.
Le 21 octobre à 3 h 02 UTC, soit 5 h 02 à Paris, des règles de protection contre PHP2Shell étaient activées par défaut pour les clients utilisant son pare-feu applicatif (Web Application Firewall ou WAF), y compris sur l’offre gratuite.
Cloudflare souligne que les protections contre PHP2Shell nécessitent davantage qu’une simple analyse des requêtes entrantes.
Certaines tentatives d’exploitation ne peuvent être correctement distinguées du trafic légitime qu’en examinant également la réponse du serveur.
Pour répondre à cette difficulté, Cloudflare a introduit un dispositif appelé Full Transaction Detection, qui rapproche les signaux observés dans la requête HTTP et dans la réponse correspondante.
L’entreprise indique également avoir observé des tentatives d’attaque et des variations des charges malveillantes destinées à contourner les règles déployées.
Cette protection à la périphérie du réseau constitue toutefois une mesure de réduction du risque, et non une correction du moteur PHP.
OVHcloud : mobilisation sur les hébergements mutualisés
En France, OVHcloud a également communiqué sur les vulnérabilités et les mesures appliquées.
Sur sa plateforme officielle de suivi des opérations Web Hosting, l’hébergeur indique avoir activé une mesure d’atténuation dès le 21 octobre à 8 heures UTC, puis déployé des règles de filtrage WAF.
À 17 h 53 UTC, soit 19 h 53 à Paris, OVHcloud confirmait que les versions PHP de 7.4 à 8.5 avaient été corrigées sur l’ensemble de ses clusters d’hébergement mutualisé.
Cette communication concerne expressément les hébergements web administrés par OVHcloud.
Elle ne signifie pas que les clients disposant de serveurs VPS ou de machines dédiées bénéficient automatiquement du même niveau de mise à jour. Sur ces infrastructures, l’installation et la maintenance du système d’exploitation et de PHP restent généralement sous la responsabilité de l’administrateur.
Une coordination internationale sous forte pression
D’autres fournisseurs de sécurité et distributeurs ont préparé leurs signatures de détection, leurs paquets corrigés et leurs procédures de déploiement.
Les centres nationaux de cybersécurité ont rapidement relayé les alertes, parmi lesquels le CERT-FR en France, le CERT-EU au niveau européen et le National Cyber Security Centre des Pays-Bas.
Les versions officiellement corrigées de PHP ont finalement été publiées le 21 octobre, autour de 13 h 30 UTC selon le CERT-EU.
Cette mobilisation constitue un exemple marquant de coordination entre développeurs open source, entreprises privées, fournisseurs cloud et autorités publiques.
Le 21 octobre : des centaines de sites mis hors ligne par précaution
L’une des conséquences les plus visibles de PHP2Shell a été la suspension temporaire de nombreux services en ligne.
Plutôt que de laisser des applications potentiellement vulnérables accessibles pendant l’installation des correctifs, certaines organisations ont préféré interrompre leurs services.
Le phénomène a particulièrement concerné les administrations, les infrastructures publiques et des institutions disposant de systèmes critiques.
En France : des sites de préfectures temporairement désactivés
Le ministère de l’Intérieur a confirmé la mise hors ligne temporaire de sites de préfectures dans l’attente de correctifs de sécurité.
Cette mesure était préventive.
Il ne faut donc pas interpréter ces interruptions comme la preuve d’une compromission des sites concernés.
En Europe : une mobilisation particulièrement étendue
En Allemagne, le prestataire informatique fédéral ITZBund a suspendu plusieurs sites administratifs.
Aux Pays-Bas, de nombreuses organisations ont suivi les recommandations de leur centre national de cybersécurité. Des services gouvernementaux, des établissements hospitaliers et le port de Rotterdam figurent parmi les organisations ayant pris des mesures préventives.
En Finlande, le centre informatique de l’État, Valtori, a procédé à la suspension de services publics. L’organisme a indiqué qu’il s’agissait d’une précaution et non de la conséquence d’une fuite de données.
En Belgique, le ministère des Affaires étrangères a temporairement interrompu l’accès à certains sites après des signalements d’attaques potentielles, sans qu’une compromission des sites belges ait été confirmée par le centre national de cybersécurité.
En République tchèque, le gouvernement a également rendu temporairement inaccessible son site afin de permettre l’installation des correctifs.
Des plateformes internationales concernées
La Wikimedia Foundation, qui exploite notamment Wikipédia, a confirmé que ses systèmes reposant sur PHP étaient concernés par les vulnérabilités.
Elle a annoncé la suspension préventive de plusieurs systèmes, sans que cela signifie une interruption générale de Wikipédia.
D’autres organisations à travers le monde ont également choisi de limiter l’accès à certains services pendant leurs opérations de sécurisation.
Ces mises hors ligne ont constitué une forme de confinement numérique préventif.
Elles illustrent un arbitrage devenu central en cybersécurité : accepter une interruption temporaire de disponibilité pour réduire le risque d’une compromission potentiellement bien plus coûteuse.
Quelles solutions temporaires ont permis de réduire les risques ?
Avant la disponibilité des correctifs, les administrateurs devaient composer avec une situation difficile : les vulnérabilités étaient suffisamment graves pour justifier une action immédiate, mais les solutions définitives n’étaient pas encore accessibles à tous.
Plusieurs mesures d’atténuation ont donc été proposées.
Le filtrage du trafic avec un WAF
Un pare-feu applicatif peut identifier et bloquer certaines requêtes suspectes avant qu’elles n’atteignent le serveur PHP.
Les protections de Cloudflare et d’autres fournisseurs relèvent de cette logique.
Elles peuvent limiter les attaques connues, mais ne garantissent pas une protection contre toutes les variantes possibles.
La désactivation de certaines fonctions PHP
Le CERT-FR a notamment recommandé, à titre provisoire, la désactivation de la fonctionnalité session.upload_progress.
Cette mesure réduit certains chemins d’exploitation associés à la seconde vulnérabilité.
L’équipe PHP recommande également, dans des conditions précises, des restrictions de taille et de complexité des requêtes, ainsi que des adaptations de la gestion mémoire.
Parmi les mesures documentées figure le réglage memory_limit=-1 pour réduire un scénario d’exploitation de la première faille. Cette configuration ne doit toutefois pas être appliquée sans étude de ses conséquences sur la consommation mémoire et la disponibilité des serveurs.
Ces ajustements peuvent perturber certaines fonctionnalités applicatives, en particulier les transferts de fichiers.
L’isolement ou la suspension temporaire
Lorsque les correctifs sont indisponibles ou impossibles à déployer immédiatement, le CERT-EU recommande d’envisager l’isolement des applications vulnérables vis-à-vis des réseaux publics.
Pour les services les plus sensibles, une interruption contrôlée peut donc être préférable au maintien d’une exposition non maîtrisée.
Toutes ces mesures restent des solutions transitoires. Seule l’installation d’une version corrigée de PHP apporte une réponse complète aux vulnérabilités connues.
Quels correctifs doivent être installés ?
Le 21 octobre 2026, l’équipe PHP a publié quatre versions de sécurité.
| Branche PHP | Première version officiellement corrigée |
|---|---|
| PHP 8.5 | 8.5.12 |
| PHP 8.4 | 8.4.27 |
| PHP 8.3 | 8.3.36 |
| PHP 8.2 | 8.2.35 |
Les versions plus anciennes de ces branches restent vulnérables en l’absence de correctif fourni par le distributeur.
La situation est plus délicate pour PHP 8.1 et les branches antérieures, qui ne bénéficient plus du support de sécurité normal du projet PHP.
Compte tenu de la gravité de l’incident, l’équipe PHP a exceptionnellement publié des correctifs minimaux sous forme de code source pour PHP 7.4, 8.0 et 8.1.
Ces correctifs ne constituent pas une reprise générale du support de ces versions obsolètes.
Certains fournisseurs Linux et prestataires de support à long terme peuvent aussi intégrer les corrections dans leurs propres paquets. Dans ce cas, le numéro affiché par PHP ne reflète pas toujours directement l’état réel des correctifs.
Il convient donc de vérifier l’origine des paquets installés, les avis de sécurité du fournisseur et la version réellement utilisée par les processus web.
Au 22 octobre : que doivent faire les entreprises qui n’ont pas encore corrigé leurs serveurs ?
Pour les entreprises qui n’ont pas installé les correctifs au 22 octobre, la situation exige une mobilisation rapide des équipes informatiques.
Il ne suffit pas de vérifier le site public de l’entreprise : certaines applications moins visibles peuvent également utiliser PHP.
Identifier toutes les installations PHP
La première priorité consiste à établir un inventaire précis des environnements concernés.
Cela inclut les serveurs web, VPS, machines virtuelles, conteneurs Docker, applications métiers, interfaces d’administration, plateformes de préproduction et logiciels intégrant PHP.
Les entreprises doivent également vérifier la situation de leurs prestataires d’hébergement et de leurs éditeurs SaaS.
Corriger, redémarrer et vérifier
La deuxième priorité est le déploiement des versions corrigées ou des paquets de sécurité fournis par les distributeurs.
Une simple installation ne suffit pas toujours : il faut s’assurer que les processus PHP-FPM, Apache ou les conteneurs utilisent effectivement la version corrigée après redémarrage.
Une validation fonctionnelle des applications essentielles reste nécessaire, notamment pour les paiements, les formulaires, les connexions clients et les échanges avec les systèmes métiers.
Examiner les signes d’une exploitation antérieure
La publication d’un correctif ne garantit pas qu’un serveur n’a pas été attaqué auparavant.
Les entreprises doivent donc analyser leurs journaux web et système, les événements remontés par leurs WAF ou solutions EDR, les erreurs inhabituelles de PHP et les modifications suspectes des fichiers applicatifs.
La surveillance doit particulièrement porter sur les comportements anormaux des processus web, les créations de fichiers inattendues et les connexions sortantes inhabituelles.
Si une compromission est suspectée, une investigation dédiée doit être menée avant de considérer l’infrastructure comme saine. Selon les résultats, une reconstruction des systèmes et une rotation des identifiants compromis peuvent être nécessaires.
Pour les équipes marketing et digitales
Les responsables marketing, e-commerce et MarTech ont également un rôle à jouer.
Ils doivent s’assurer que leurs sites, landing pages, boutiques, portails clients et plateformes de campagne disposent bien des correctifs nécessaires.
Une attention particulière doit être portée aux connexions entre les sites PHP et les CRM, CDP, outils d’analytics et systèmes de gestion des données clients.
La responsabilité opérationnelle des correctifs revient aux équipes techniques ou aux prestataires concernés, mais la continuité des parcours clients et la protection des données constituent des enjeux métiers directs.
Point de situation au 22 octobre 2026
Au lendemain de la publication des correctifs, plusieurs constats peuvent déjà être établis.
Les correctifs sont disponibles. Les principales branches officiellement maintenues de PHP disposent de versions permettant de corriger les deux vulnérabilités.
Les protections périphériques ont été activées chez plusieurs fournisseurs. Cloudflare et OVHcloud ont notamment communiqué sur le déploiement de mesures de filtrage et de correctifs dans les environnements qu’ils administrent.
Des tentatives d’exploitation sont signalées. Cloudflare affirme avoir observé des requêtes malveillantes et des adaptations des charges d’attaque. Des preuves de concept ont également commencé à circuler publiquement.
Il faut toutefois distinguer les tentatives détectées, les démonstrations réalisées en laboratoire et les compromissions effectivement confirmées.
Au moment de la divulgation, la PHP Foundation indiquait ne pas avoir identifié d’exploit fonctionnel parmi les preuves de concept examinées. Cela ne permet pas d’exclure d’autres tentatives ou exploitations, et la visibilité disponible reste nécessairement partielle.
La principale incertitude concerne désormais l’étendue réelle des infrastructures encore vulnérables et l’éventuelle exploitation des systèmes non corrigés.
Il est trop tôt pour établir un bilan définitif des conséquences de PHP2Shell.
La capacité des grandes plateformes à déployer rapidement les correctifs contraste probablement avec les difficultés rencontrées par certaines PME, petites organisations, administrations et applications anciennes.
C’est sur ces environnements que le risque pourrait se prolonger.
Deux autres incidents majeurs, sans lien établi avec PHP2Shell
La séquence du 20 au 22 octobre 2026 a également été marquée par deux pannes importantes touchant les réseaux de télécommunications et le cloud.
Leur proximité dans le temps peut susciter des interrogations, mais aucun élément public vérifié ne permet d’établir un lien causal entre ces incidents et les vulnérabilités PHP2Shell, ni entre les deux pannes elles-mêmes.
Orange : une défaillance dans le cœur du réseau mobile français
Le mercredi 21 octobre, les clients d’Orange et de Sosh ont subi d’importantes perturbations des services mobiles en France.
Les appels, les SMS et les communications de données ont été fortement affectés pour une partie des abonnés, particuliers comme entreprises.
L’incident a commencé en fin de matinée et s’est prolongé pendant plusieurs heures.
Dans un premier communiqué, Orange a confirmé une perturbation majeure de son réseau mobile, précisant que les appels d’urgence n’étaient pas impactés.
Dans la soirée, l’opérateur a annoncé le rétablissement de ses services et communiqué sur l’origine technique de l’incident : la défaillance d’un équipement situé dans le cœur de son réseau mobile.
Cette explication ne désigne pas une vulnérabilité PHP ni une cyberattaque.
Des hypothèses techniques plus précises ont circulé dans les médias, mais l’explication officielle disponible se limite à cette défaillance d’équipement.
Google Cloud à Londres : une panne électrique aux conséquences bancaires
La veille, mardi 20 octobre, une autre défaillance majeure avait affecté Google Cloud dans sa région londonienne europe-west2.
Selon la plateforme officielle Google Cloud Service Health, l’incident a commencé à 6 h 08 UTC, soit 8 h 08 à Paris, et a duré près de huit heures.
Google a identifié un événement électrique (power event) affectant la zone europe-west2-b.
La panne a provoqué une indisponibilité de nombreux services cloud et des erreurs sur plusieurs produits de la plateforme.
Plusieurs établissements financiers britanniques, notamment Lloyds, HSBC et Revolut, ont rencontré des perturbations de leurs services numériques.
Au-delà de la défaillance électrique elle-même, cet incident a relancé les interrogations sur la concentration des infrastructures critiques auprès d’un nombre limité de fournisseurs cloud.
Trois incidents distincts, un même enjeu : la résilience numérique
Ces trois événements ne doivent pas être confondus.
- PHP2Shell résulte de vulnérabilités logicielles pouvant être exploitées par des attaquants.
- La panne Orange provient, selon l’opérateur, d’une défaillance d’équipement dans une infrastructure de télécommunications.
- L’incident Google Cloud est associé à un problème électrique dans une zone de son infrastructure londonienne.
Leurs origines sont différentes, tout comme les mesures nécessaires pour y répondre.
Mais leur juxtaposition met en évidence une réalité fondamentale : les services numériques reposent sur une succession de dépendances, dont certaines restent peu visibles pour les utilisateurs et parfois pour les entreprises elles-mêmes.
Un site marchand peut être correctement développé, mais dépendre d’une version vulnérable de PHP.
Une application bancaire peut être parfaitement sécurisée sur le plan logiciel, mais devenir indisponible en raison d’une panne dans un centre de données.
Un service mobile peut cesser de fonctionner alors que les applications de ses utilisateurs sont opérationnelles.
La cybersécurité et la résilience numérique ne se limitent donc plus à protéger les applications contre des attaques. Elles impliquent également de maîtriser les dépendances techniques, les risques fournisseurs et les capacités de continuité de service.
En conclusion : PHP2Shell révèle une transformation profonde de la cybersécurité
PHP2Shell pourrait devenir un événement de référence dans l’histoire récente de la sécurité informatique.
Non seulement en raison de la gravité des failles découvertes, mais surtout par la combinaison de plusieurs facteurs : l’ancienneté des vulnérabilités, leur présence dans une technologie omniprésente, l’intervention de systèmes d’intelligence artificielle dans leur découverte et la rapidité de la mobilisation internationale.
L’incident pose notamment une question centrale : que se passera-t-il lorsque les systèmes d’IA seront capables d’identifier et de rendre exploitables des vulnérabilités complexes beaucoup plus vite que les éditeurs ne pourront les corriger et les entreprises les déployer ?
La réponse ne peut pas reposer uniquement sur l’amélioration des outils de détection.
Elle nécessitera aussi des investissements dans la maintenance des logiciels open source, des mécanismes de divulgation coordonnée plus robustes, une automatisation maîtrisée des correctifs et une meilleure connaissance des dépendances applicatives.
L’épisode révèle également une contradiction : certaines technologies essentielles au fonctionnement de l’économie numérique sont maintenues par des équipes relativement réduites, alors qu’elles supportent des milliers de services et des millions d’interactions quotidiennes.
Pour les entreprises, la leçon dépasse donc largement PHP.
La sécurité d’un service numérique dépend autant de son code que de l’ensemble des infrastructures, bibliothèques, fournisseurs et composants qui le rendent possible.
Et à mesure que l’intelligence artificielle accélère la découverte des vulnérabilités, le temps disponible pour agir pourrait devenir l’une des ressources les plus précieuses de la cybersécurité.
Le véritable enjeu de l’après-PHP2Shell ne sera pas seulement de corriger deux failles. Il sera de déterminer si nos organisations peuvent apprendre à sécuriser leurs infrastructures aussi vite que l’intelligence artificielle apprend à en découvrir les faiblesses.
Quelques références
- « Today’s PHP Security Release, and How We’re Strengthening PHP Security » — The PHP Foundation — The PHP Foundation — octobre 2026.
- « Security advisory: Critical remote code execution vulnerabilities, update now » — PHP Development Team — PHP.net — octobre 2026.
- « PHP2Shell: AI uncovers critical RCE vulnerabilities affecting 70% of the Internet » — Sagi Tzadik, Shir Tamari, Nir Ohfeld et Tomer Schwartz — Wiz Research — octobre 2026.
- « Patch the Planet: global response coordination as agents uncover critical vulnerabilities » — OpenAI — OpenAI — octobre 2026.
- « Cloudflare deploys protections against php2shell vulnerability » — Daniele Molteni, Dan Jones et Kuber Nandwani — Cloudflare Blog — octobre 2026.
- « Multiples vulnérabilités dans PHP » — CERT-FR / ANSSI — CERT-FR — octobre 2026.
- « Critical Vulnerabilities in PHP » — CERT-EU — CERT-EU Security Advisory 2026-018 — octobre 2026.
- « Web Hosting — All clusters maintenance notification » — OVHcloud Web Cloud Status — octobre 2026.
- « Websites taken offline over PHP risks » — Anzar Mehraj, Prathik Jayaprakash et Jason Hovet — Reuters, repris par Euronext — octobre 2026.
- « Rétablissement du réseau mobile d’Orange France » — Groupe Orange — octobre 2026.
- « Multiple services were experiencing issues in the europe-west2 region » — Google Cloud Service Health — octobre 2026.
- « Usage statistics of PHP for websites » — W3Techs / Q-Success — W3Techs — octobre 2026.
Note éditoriale : cet article présente les informations publiques vérifiables au matin du 22 octobre 2026. Les données relatives aux tentatives d’exploitation, aux compromissions éventuelles et aux déploiements de correctifs peuvent évoluer rapidement.
