Une faille PHP évaluée à 9,2 sur 10 pourrait concerner près de 70 % des sites web dont le langage serveur est identifiable. Les vulnérabilités, baptisées PHP2Shell, permettent notamment l’exécution de code à distance sans authentification, avec un risque direct pour les serveurs, les données et la disponibilité des services.
L’alerte publiée le 21 octobre 2026 marque aussi un tournant dans la cybersécurité : une équipe de Calif, avec l’aide du modèle GPT-5.6 Sol d’OpenAI, a découvert l’une des failles, tandis que Wiz identifiait indépendamment les vulnérabilités. Les correctifs ont été préparés avec plusieurs acteurs avant la divulgation publique, afin de réduire la fenêtre d’exploitation par des attaquants.
PHP2Shell expose le socle technique d’une grande partie du Web
Le risque ne vient pas d’une extension isolée ni d’un site particulier, mais du moteur PHP exécuté par les serveurs web. PHP est utilisé par près de 70 % des sites dont le langage côté serveur peut être identifié, selon les données de W3Techs relayées par plusieurs médias spécialisés.
Cette présence explique l’ampleur de l’alerte. PHP fait fonctionner des sites éditoriaux, des services publics et des applications s’appuyant sur des plateformes comme WordPress, Drupal ou Joomla. Une vulnérabilité du runtime peut donc dépasser très largement le périmètre d’un éditeur ou d’un fournisseur d’hébergement.
Les deux failles ont reçu les identifiants CVE-2026-109618 et CVE-2026-109619. Cloudflare indique qu’elles touchent les serveurs exécutant PHP 5.4 ou une version ultérieure et qu’elles peuvent provoquer un déni de service, une exécution de code à distance et une exposition de données lorsqu’un serveur traite un trafic HTTP spécialement conçu.
À retenir : PHP2Shell vise la couche logicielle qui exécute les applications web. La mise à jour doit donc porter sur PHP lui-même, et pas seulement sur le CMS ou les extensions installées.
Une exécution de code sans compte change immédiatement le niveau de risque
Les vulnérabilités sont classées 9,2 sur 10 selon l’échelle CVSS v4.0, un standard utilisé pour mesurer la gravité des failles informatiques. Cette note correspond à un scénario où un attaquant peut envoyer des requêtes à distance et exécuter des commandes sans disposer d’un compte sur le service visé.
Une telle capacité peut permettre de modifier le contenu d’un site, d’interrompre un service ou d’accéder à des informations traitées par le serveur. Les données exposées peuvent inclure des secrets d’application, des identifiants techniques ou des informations appartenant aux utilisateurs, selon la configuration du système compromis.
Wiz a indiqué avoir démontré des attaques contre des installations WordPress, Drupal et Joomla. Ces plateformes ne constituent pas nécessairement la cause de la faille : elles peuvent être affectées lorsqu’elles s’exécutent sur un environnement PHP vulnérable.
Les conséquences dépendent toutefois de l’architecture de chaque organisation. Un serveur isolé, correctement cloisonné et dépourvu de données sensibles ne présente pas le même impact qu’un serveur connecté à une base clients, à des outils internes ou à plusieurs applications.
L’IA intervient avant l’attaque, pas seulement après l’incident
La découverte attribuée à Calif et OpenAI illustre un changement de rôle pour l’IA en cybersécurité. Le modèle GPT-5.6 Sol a été utilisé pour aider des chercheurs à identifier une faille critique dans le moteur PHP, dans le cadre de l’initiative Patch the Planet.
OpenAI a indiqué que cette découverte s’inscrivait dans une collaboration réunissant des mainteneurs, des chercheurs et des fournisseurs de sécurité. La vulnérabilité signalée par Calif a été communiquée à PHP le 11 août 2026, tandis que Wiz a découvert et signalé une seconde faille le 24 août, selon les informations rapportées par Reuters.
« Les modèles d’OpenAI ont aidé des chercheurs [...] à découvrir des failles critiques dans PHP », a indiqué OpenAI dans une publication consacrée à Patch the Planet.
L’intérêt opérationnel ne réside pas uniquement dans la détection automatisée d’un défaut. L’IA peut aussi accélérer l’exploration de chemins d’exécution complexes, la génération de cas de test et l’analyse de grandes quantités de code. Dans le cas de PHP2Shell, cette capacité a contribué à donner aux mainteneurs et aux fournisseurs de sécurité du temps pour préparer les correctifs avant la publication.
OpenAI présente cette séquence comme un exemple de « Defender’s Window », c’est-à-dire une période pendant laquelle les défenseurs connaissent une faiblesse avant son exploitation publique par des attaquants. Cette fenêtre reste limitée : dès que les détails techniques deviennent publics, les organisations non corrigées deviennent des cibles potentielles.
Calif, Wiz et OpenAI n’ont pas joué le même rôle
La chronologie publiée autour de PHP2Shell distingue plusieurs contributions. Calif a travaillé avec OpenAI pour identifier la première faille à l’aide de GPT-5.6 Sol. Wiz a, de son côté, découvert les vulnérabilités indépendamment et a également utilisé des modèles d’IA dans ses travaux de recherche, selon les informations relayées par CNN et Reuters.
| Acteur | Contribution documentée | Élément technique associé |
|---|---|---|
| Calif | Découverte d’une vulnérabilité avec l’aide d’OpenAI | Signalement à PHP le 11 août 2026 |
| OpenAI | Mise à disposition de GPT-5.6 Sol et coordination de Patch the Planet | Recherche de failles dans PHP |
| Wiz | Découverte indépendante et analyse des vulnérabilités | Signalement d’une faille le 24 août 2026 |
| PHP | Publication des correctifs et des versions mises à jour | CVE-2026-109618 et CVE-2026-109619 |
| Cloudflare | Déploiement de protections côté infrastructure | Règles de protection pour PHP2Shell |
Cette répartition est importante pour comprendre la tendance. L’IA ne remplace pas les chercheurs, les mainteneurs ou les équipes de réponse à incident. Elle s’intègre dans une chaîne qui va de la recherche de vulnérabilités à la validation du correctif, puis à la protection des systèmes exposés.
La découverte indépendante par plusieurs équipes renforce aussi la nécessité d’un processus de divulgation coordonnée. Une faille présente dans un composant aussi répandu peut être détectée par plusieurs groupes avant sa publication, ce qui impose de partager rapidement les informations utiles sans augmenter prématurément le risque d’exploitation.
Les correctifs PHP deviennent une priorité d’exploitation
L’équipe de développement de PHP a publié des mises à jour le 21 octobre 2026 et a demandé à tous les utilisateurs de mettre à niveau leurs installations. Les administrateurs qui dépendent d’une distribution Linux ou d’un service de support à long terme doivent également vérifier la disponibilité des paquets corrigés auprès de leur fournisseur.
Les actions prioritaires sont concrètes :
- Identifier les serveurs exécutant PHP, y compris ceux gérés par un hébergeur ou une plateforme interne.
- Vérifier les versions installées et les paquets fournis par le système d’exploitation.
- Installer une version corrigée de PHP dès qu’elle est disponible dans l’environnement concerné.
- Contrôler les journaux HTTP, les processus inhabituels et les modifications récentes de fichiers.
- Appliquer les mesures de protection proposées par les fournisseurs d’infrastructure.
- Isoler temporairement les services qui ne peuvent pas être mis à jour immédiatement.
Cloudflare a annoncé le déploiement de protections WAF contre PHP2Shell. Un WAF, ou pare-feu applicatif web, inspecte les requêtes HTTP et peut bloquer certains comportements malveillants avant qu’ils n’atteignent l’application.
Une règle WAF ne remplace toutefois pas la mise à jour du runtime. Elle réduit l’exposition pendant la remédiation, mais ne supprime pas la vulnérabilité présente sur le serveur. La correction durable consiste à installer une version de PHP contenant les correctifs appropriés.
Les sites publics et les médias ont choisi la mise hors ligne
Des sites gouvernementaux et de médias ont été mis hors ligne le 21 octobre afin de traiter la vulnérabilité. Les autorités européennes ont recommandé aux organisations incapables d’appliquer rapidement les correctifs de retirer les services concernés d’Internet.
Cette décision traduit un arbitrage inhabituel entre disponibilité et sécurité. Un site public indisponible pendant une opération de maintenance peut perturber l’accès à l’information, mais un serveur compromis peut exposer des données, servir à des attaques secondaires ou devenir une base pour pénétrer d’autres systèmes.
Le FBI, la NSA et les services américains spécialisés dans la cybersécurité ont également recommandé aux organisations utilisant PHP de retirer les installations vulnérables ou de les mettre à jour. Les recommandations s’adressent donc autant aux administrations qu’aux entreprises et aux opérateurs de services numériques.
Le risque systémique vient de la réutilisation des mêmes composants. Un fournisseur d’hébergement peut administrer des centaines ou des milliers de sites reposant sur des versions proches de PHP. Une erreur de déploiement, une version oubliée ou une dépendance non suivie peut alors prolonger l’exposition bien après la publication d’un correctif.
Ce que PHP2Shell change pour les équipes de sécurité
PHP2Shell montre que la surface d’attaque ne se limite plus aux applications visibles par les utilisateurs. Le composant vulnérable peut se trouver dans une couche technique commune à de nombreux services, parfois éloignée des équipes qui gèrent le contenu ou le design du site.
Cette situation impose une meilleure cartographie des actifs. Une organisation doit savoir quels domaines utilisent PHP, quelles versions sont installées, quels serveurs hébergent plusieurs applications et quelles bases de données sont accessibles depuis ces environnements.
Elle doit également revoir ses mécanismes de gestion des correctifs. Une alerte critique évaluée à 9,2 sur 10 ne peut pas suivre le même calendrier qu’une mise à jour fonctionnelle ordinaire. Les responsables doivent disposer d’un inventaire fiable, de procédures d’urgence et de tests suffisamment rapides pour éviter de retarder le déploiement.
L’IA peut renforcer chacune de ces étapes :
- Détecter des versions vulnérables dans un inventaire technique.
- Examiner le code et les dépendances à la recherche de chemins d’exploitation.
- Générer des tests pour vérifier qu’un correctif bloque le comportement dangereux.
- Trier les journaux afin d’identifier des signes d’exploitation.
- Prioriser les systèmes selon leur exposition et la sensibilité des données.
La limite reste la validation humaine. Une alerte produite par un modèle doit être reproduite, comprise et évaluée dans le contexte de l’architecture concernée. Une automatisation trop agressive peut interrompre un service légitime, tandis qu’une automatisation trop prudente peut laisser une faille exploitable en production.
Notre avis : l’IA devient un accélérateur, pas un bouclier automatique
PHP2Shell confirme une évolution nette : l’IA peut contribuer à découvrir des vulnérabilités dans des composants d’infrastructure avant leur exploitation publique. La portée potentielle de PHP, la gravité CVSS de 9,2 et l’exécution de code sans authentification expliquent la réaction immédiate des éditeurs, des gouvernements et des fournisseurs de sécurité.
Mais l’IA ne protège pas automatiquement les 70 % de sites concernés. La défense dépend encore de la capacité des organisations à inventorier leurs serveurs, installer les versions corrigées, surveiller les journaux et isoler les systèmes qui ne peuvent pas être mis à jour.
Dans les six prochains mois, la pression devrait se déplacer vers l’automatisation de la réponse : détection continue des versions vulnérables, tests de correctifs assistés par modèle et blocage temporaire des requêtes malveillantes. Les entreprises qui traiteront l’IA comme un outil intégré à leur chaîne de remédiation prendront une longueur d’avance sur celles qui la limitent à la génération de code ou à l’analyse après incident.
La question n’est donc plus de savoir si l’IA peut trouver une faille critique, mais combien de temps les équipes humaines mettront à corriger chaque système exposé après sa découverte.