Deux vulnérabilités critiques touchant PHP déclenchent une alerte de sécurité à l’échelle internationale. Référencées sous les identifiants CVE-2026-109618 et CVE-2026-109619, ces failles sont associées à un risque d’exécution de code à distance (RCE), une catégorie de vulnérabilités particulièrement dangereuse pour les serveurs exposés à Internet.
Baptisées PHP2Shell dans les premières publications consacrées à l’affaire, les deux failles ont reçu une note de 9,2 sur 10 selon le référentiel CVSS v4.0. Le 21 octobre 2026, l’équipe de sécurité de PHP a annoncé une mise à jour d’urgence prévue à 14 h UTC, en invitant les administrateurs à préparer immédiatement leurs systèmes. L’annonce officielle de PHP précise que les détails techniques, les versions concernées et les versions corrigées doivent être publiés avec les correctifs.
L’urgence est renforcée par des informations contradictoires sur les premières tentatives d’exploitation : Cloudflare a signalé des signes d’activité malveillante émergente, tandis que le centre australien de cybersécurité indiquait ne pas disposer, à ce stade, de preuves confirmées d’exploitation active. Les organisations doivent donc se préparer sans attendre une confirmation généralisée des attaques.
PHP2Shell : que sait-on des deux vulnérabilités ?
Les deux failles sont identifiées par les références suivantes :
- CVE-2026-109618
- CVE-2026-109619
Selon les premières analyses publiées par des spécialistes de la cybersécurité, elles pourraient permettre à un attaquant distant d’exécuter du code sur un serveur vulnérable. Une telle capacité peut transformer une vulnérabilité dans le moteur PHP en point d’entrée vers une application web, ses données et, potentiellement, d’autres ressources accessibles depuis le serveur.
Le terme RCE (Remote Code Execution) désigne précisément la possibilité de faire exécuter des instructions par une machine à distance. Lorsque cette exécution peut être déclenchée sans authentification, le risque est particulièrement élevé : l’attaquant n’a pas nécessairement besoin de disposer d’un compte légitime pour tenter de compromettre le système.
Il faut néanmoins distinguer les informations confirmées des éléments encore en cours d’analyse. Au moment de la publication de l’avis préliminaire, l’équipe de sécurité de PHP n’avait pas encore détaillé publiquement les causes techniques des deux failles ni confirmé officiellement toutes les versions touchées. Les descriptions techniques diffusées avant la publication des correctifs doivent donc être considérées avec prudence.
Le site spécialisé Tenable confirme les identifiants CVE et les scores CVSS 4.0 de 9,2, tout en soulignant que les détails techniques officiels restent déterminants pour établir précisément le périmètre de vulnérabilité.
Pourquoi une vulnérabilité PHP peut-elle menacer autant de sites web ?
PHP est largement utilisé pour produire des pages web dynamiques et faire fonctionner des applications côté serveur. Il intervient dans de nombreux systèmes de gestion de contenu, plateformes de commerce électronique et applications métiers.
L’écosystème comprend notamment :
- WordPress et de nombreux de ses composants ;
- Drupal et Joomla ;
- Magento et d’autres plateformes de commerce électronique ;
- des applications PHP développées sur mesure ;
- des services d’hébergement mutualisé et des environnements de gestion de serveurs.
La présence de PHP ne signifie pas automatiquement qu’un site est vulnérable à PHP2Shell. Le risque dépend de la version du moteur, de la configuration, de l’exposition des composants concernés et, surtout, des versions corrigées officiellement publiées.
Cependant, lorsqu’une faille affecte le moteur PHP lui-même, la protection ne peut pas reposer uniquement sur une mise à jour du CMS ou d’une extension. Un site WordPress à jour peut toujours dépendre d’un moteur PHP vulnérable si l’environnement d’hébergement n’a pas été corrigé.
Dans un article publié le 21 octobre, Reuters rapporte que les autorités de cybersécurité européennes ont recommandé aux organisations incapables d’appliquer rapidement les correctifs d’envisager de retirer temporairement les sites concernés d’Internet.
Quels sont les risques en cas d’exploitation réussie ?
Une vulnérabilité RCE peut avoir des conséquences différentes selon les privilèges du processus PHP, les contrôles de sécurité en place et l’architecture du serveur.
Prise de contrôle du serveur web
Si l’attaquant parvient à exécuter des commandes avec les droits du processus PHP, il peut potentiellement accéder aux fichiers de l’application, modifier certains contenus ou installer des composants malveillants.
L’impact peut être plus important si le processus PHP dispose de privilèges excessifs ou si le serveur permet d’accéder à des systèmes internes.
Vol de données et exposition des secrets
Les applications web utilisent souvent des fichiers de configuration qui contiennent des identifiants de bases de données, des clés d’API ou d’autres secrets techniques. Un attaquant ayant obtenu un accès suffisant peut chercher à récupérer ces informations.
Les conséquences peuvent dépasser le site initialement compromis si les identifiants récupérés permettent de se connecter à des bases de données, à des services cloud ou à d’autres applications.
Modification de sites et distribution de logiciels malveillants
Un serveur compromis peut être utilisé pour altérer des pages, injecter des scripts malveillants, rediriger les visiteurs vers des sites frauduleux ou héberger des fichiers dangereux.
Pour un site marchand, une compromission peut également affecter les commandes, les données clients ou la confiance des utilisateurs.
Déplacement vers d’autres systèmes
Si le serveur vulnérable dispose d’accès réseau étendus, l’attaquant peut tenter d’utiliser cette première compromission pour atteindre d’autres ressources. Ce risque est particulièrement important dans les environnements où les serveurs web communiquent directement avec des bases de données, des systèmes d’administration ou des applications internes.
Ces scénarios représentent les conséquences possibles d’une RCE réussie ; ils ne signifient pas que toutes ces activités ont été observées dans le cadre de PHP2Shell.
Les attaques ont-elles déjà commencé ?
La situation nécessite une lecture nuancée.
Le 21 octobre, Dane Knecht, directeur technique de Cloudflare, a déclaré que des signes de premières attaques apparaissaient et que l’entreprise renforçait ses mécanismes de filtrage en attendant la disponibilité des correctifs. Il a toutefois présenté ces mesures comme une protection provisoire, et non comme un remplacement de la mise à jour.
À l’inverse, l’Australian Cyber Security Centre (ACSC) indiquait ne pas avoir connaissance d’une exploitation active confirmée des vulnérabilités au moment de son avis. Ces deux déclarations ne sont pas nécessairement incompatibles : des tentatives peuvent être observées par un fournisseur sans qu’une exploitation réussie à grande échelle soit établie.
Le risque est également lié à la publication des détails techniques. Lorsqu’une vulnérabilité devient mieux documentée, les attaquants peuvent concevoir des tests ou adapter des outils pour identifier les systèmes exposés.
Le spécialiste de la sécurité des applications JFrog recommande donc aux organisations de préparer leurs mises à jour et de ne pas interpréter l’absence d’incident détecté comme une preuve que leurs serveurs sont à l’abri.
Correctifs PHP : les administrateurs doivent se préparer sans attendre
L’équipe de sécurité de PHP a annoncé une publication d’urgence le 21 octobre 2026 à 14 h UTC. L’avis préliminaire précise que les versions corrigées et le périmètre exact des versions affectées seront communiqués avec la publication.
Il est donc essentiel de vérifier les informations directement sur le site officiel de PHP, puis d’appliquer les versions corrigées adaptées à chaque environnement dès qu’elles sont disponibles.
Les organisations devraient notamment :
- Inventorier leurs environnements PHP, y compris les serveurs de production, de préproduction, les conteneurs et les instances hébergées chez des prestataires.
- Identifier les versions réellement utilisées, en vérifiant les environnements d’exécution et non seulement la version déclarée par le CMS.
- Préparer et tester les mises à jour, afin de limiter les interruptions de service au moment du déploiement.
- Mettre à jour le moteur PHP lui-même, car la mise à jour de WordPress, Drupal ou d’une extension ne corrige pas automatiquement une faille du moteur.
- Vérifier les environnements anciens, qui peuvent ne plus bénéficier des correctifs de sécurité officiels.
- Contrôler les journaux et les alertes, notamment les comportements inhabituels des processus web, les modifications de fichiers et les connexions sortantes inattendues.
Pour les organisations qui dépendent d’un hébergeur, la responsabilité opérationnelle doit être clarifiée immédiatement. Elles doivent demander quelle version de PHP est déployée, si le correctif a été appliqué et si des environnements secondaires restent vulnérables.
Que faire si le correctif n’est pas encore disponible ou ne peut pas être installé ?
En attendant une mise à jour, les mesures de réduction de risque doivent être choisies en fonction de l’architecture de chaque système. Elles ne garantissent pas une protection complète contre les vulnérabilités PHP2Shell.
Réduire l’exposition à Internet
Si un site ou un service n’a pas besoin d’être publiquement accessible, son accès peut être restreint aux utilisateurs autorisés, à un VPN ou à des plages d’adresses approuvées.
Pour les systèmes exposés dont la compromission présenterait un risque élevé, les autorités européennes recommandent d’envisager une mise hors ligne temporaire lorsque le correctif ne peut pas être appliqué à temps.
Limiter les privilèges et les accès réseau
Les processus PHP devraient fonctionner avec des droits limités. Les serveurs web ne devraient pas disposer d’un accès inutile aux systèmes internes ou aux services d’administration.
Ces mesures peuvent limiter les conséquences d’une compromission, mais elles n’empêchent pas nécessairement le déclenchement de la vulnérabilité.
Être prudent avec les règles de filtrage
Un pare-feu applicatif (WAF) ou des règles de filtrage peuvent réduire certaines formes de trafic suspect. Toutefois, en l’absence d’une compréhension complète du mécanisme exploité, il est risqué de considérer une règle générique comme une solution définitive.
Une règle trop restrictive peut aussi casser des fonctionnalités légitimes, notamment les formulaires et les transferts de fichiers. Toute mesure temporaire doit donc être testée et surveillée.
Ne pas se fier à une option de configuration isolée
Plusieurs recommandations techniques circulent déjà en ligne. Certaines peuvent réduire l’exposition dans un scénario précis, mais aucune modification de configuration ne doit être considérée comme un substitut au correctif officiel sans validation technique solide.
Le principe est simple : réduire l’exposition pendant la période d’urgence, puis installer le correctif adapté dès sa disponibilité.
Comment vérifier si son site utilise une version vulnérable ?
La première étape consiste à identifier le moteur PHP réellement utilisé par le serveur qui traite les requêtes web. La version installée sur un ordinateur local ou dans l’interface d’administration d’un CMS peut différer de celle utilisée en production.
Les administrateurs peuvent consulter les paramètres de leur environnement d’hébergement, les outils de gestion de conteneurs ou les configurations du serveur web et de PHP-FPM. Il faut aussi prendre en compte les sites secondaires, les applications oubliées et les environnements de test accessibles depuis Internet.
La vérification doit ensuite être confrontée aux versions affectées et corrigées indiquées dans l’avis officiel publié par PHP. Les premières communications évoquaient un périmètre potentiellement large, remontant à des versions anciennes, mais le périmètre définitif doit être confirmé par la documentation du fournisseur.
Pour les équipes de sécurité, l’utilisation d’un outil de gestion des actifs et d’un inventaire logiciel fiable permet de repérer plus rapidement les systèmes qui nécessitent une intervention.
Un enjeu majeur pour les hébergeurs et les entreprises
PHP2Shell illustre les difficultés rencontrées lorsqu’une vulnérabilité critique affecte un composant partagé par des millions de sites et d’applications.
Les grandes entreprises peuvent disposer d’équipes capables de tester et de déployer rapidement un correctif. Les petites structures, les associations, les commerces en ligne et les propriétaires de sites administrés par des prestataires peuvent, eux, ne pas savoir quelle version de PHP est active ni qui est responsable de sa maintenance.
Les hébergeurs ont donc un rôle essentiel à jouer : identifier les instances concernées, préparer les versions corrigées, communiquer clairement les délais de déploiement et accompagner les clients qui utilisent des environnements anciens.
Les organisations doivent, de leur côté, intégrer la maintenance du moteur PHP à leur processus de gestion des vulnérabilités. La sécurité d’un site ne dépend pas uniquement de ses extensions, de son thème ou de son code applicatif ; elle dépend aussi de la plateforme logicielle qui exécute ce code.
Conclusion : PHP2Shell impose une réaction rapide et coordonnée
Les vulnérabilités CVE-2026-109618 et CVE-2026-109619, regroupées sous le nom PHP2Shell, représentent une menace sérieuse en raison de leur score CVSS v4.0 de 9,2 et du risque d’exécution de code à distance rapporté par les chercheurs. Leur portée potentielle concerne un vaste ensemble de serveurs et d’applications reposant sur PHP.
Au 21 octobre 2026, la priorité est d’identifier les systèmes concernés, de préparer les mises à jour et de suivre les annonces officielles de PHP. Les premières indications d’activité malveillante rendent imprudent tout report injustifié de la remédiation, même si l’ampleur des exploitations réussies reste à confirmer.
Les mesures de filtrage, la restriction des accès et la surveillance renforcée peuvent réduire temporairement le risque. Elles ne remplacent pas l’installation du correctif officiel ni la vérification des systèmes après mise à jour.
SOURCE : The Hackers News
