PHP2Shell : deux failles critiques mettent les sites web sous pression
Deux vulnérabilités critiques dans PHP, le langage qui fait fonctionner une grande partie du Web, ont déclenché une mobilisation des hébergeurs et des équipes de cybersécurité. Des correctifs sont disponibles depuis le 21 octobre 2026. Pour les propriétaires de sites, notamment sous WordPress, la priorité est de vérifier que leur serveur les utilise réellement.
L’alerte touche une technologie souvent invisible pour les internautes. PHP intervient côté serveur pour générer des pages, traiter des formulaires et faire fonctionner de nombreuses applications. Lorsqu’une faille concerne ce socle logiciel, des sites très différents peuvent être exposés au même problème.
Connues sous le nom PHP2Shell, les deux vulnérabilités portent les identifiants CVE-2026-109618 et CVE-2026-109619. Elles obtiennent chacune un score de gravité de 9,2 sur 10, selon l’échelle CVSS 4.0. Elles peuvent permettre l’exécution de code à distance sans authentification : dans certaines conditions, un attaquant pourrait faire exécuter des instructions au serveur sans disposer d’un compte. Critical Vulnerabilities in PHP
« 70 % des sites web » : ce que signifie réellement ce chiffre
Le chiffre repris dans plusieurs titres donne une idée de l’importance de PHP, mais il demande une précision.
Selon W3Techs, PHP est utilisé par environ 69 % des sites dont le langage de programmation côté serveur est connu. Cette mesure porte sur l’utilisation d’une technologie, pas sur le nombre de sites compromis. Elle ne signifie donc pas que 70 % du Web a été piraté.
L’exposition réelle dépend notamment de la version installée, des correctifs appliqués et de la configuration du serveur. Un site utilisant PHP peut déjà avoir été protégé par son hébergeur, tandis qu’une installation oubliée demeure vulnérable.
Des erreurs de mémoire au cœur du problème
Les deux failles concernent la manière dont PHP gère sa mémoire lorsque le traitement d’une requête se termine anormalement.
La première touche la gestion d’un manque de mémoire : PHP peut interrompre une opération avant que certaines données internes soient complètement préparées, puis les utiliser comme si elles étaient valides.
La seconde concerne des références internes qui subsistent après la libération de la mémoire correspondante. Une requête ultérieure peut alors réutiliser cet état devenu invalide.
Selon les chercheurs de Wiz, l’exploitation de ces défauts peut permettre de lire des informations sensibles présentes en mémoire ou d’exécuter du code. Les données exposées peuvent comprendre des mots de passe, des jetons d’authentification ou des clés d’API. Le problème se situe dans PHP lui-même : une application correctement développée peut donc être concernée.
WordPress est concerné, mais une mise à jour de WP ne suffit pas
L’équipe de WordPress a publié une alerte spécifique : ces vulnérabilités ne proviennent pas du CMS et aucune mise à jour de WordPress n’est prévue pour les corriger. L’intervention doit porter sur PHP, au niveau de l’hébergement.
L’avis officiel de PHP inclut les installations servant des requêtes web avec PHP-FPM, Apache et mod_php, CGI, FrankenPHP ou LiteSpeed. Le projet considère la configuration Apache avec mod_php comme particulièrement exposée : une exploitation démontrée peut intervenir avant même l’exécution du code de l’application. php.net
Installer une extension de sécurité ou actualiser son thème ne remplace donc pas le correctif du moteur PHP.
Les versions corrigées sont disponibles
Les versions publiées le 21 octobre corrigent les deux vulnérabilités :
| Branche PHP | Version corrigée publiée |
|---|---|
| PHP 8.2 | 8.2.35 |
| PHP 8.3 | 8.3.36 |
| PHP 8.4 | 8.4.27 |
| PHP 8.5 | 8.5.12 |
PHP 8.1 et les branches plus anciennes ne reçoivent plus de mises à jour ordinaires du projet. Certains fournisseurs proposent toutefois des correctifs rétroportés. Il faut donc vérifier auprès de l’hébergeur si le paquet installé contient effectivement les corrections, plutôt que se fier uniquement au numéro de version affiché.
Des interruptions préventives, pas nécessairement des piratages
L’alerte a poussé certaines organisations à suspendre temporairement leurs services pendant les opérations de sécurisation. Reuters rapporte notamment des mises hors ligne de sites gouvernementaux. Une indisponibilité dans ce contexte ne prouve donc pas qu’un site a été compromis.
Le risque d’attaque est néanmoins concret. Cloudflare indique avoir observé du trafic malveillant visant ces vulnérabilités, ainsi que des tentatives de modification des requêtes pour contourner ses protections. L’entreprise a déployé des règles de pare-feu applicatif pour ses clients utilisant son WAF, y compris sur son offre gratuite. Elle souligne toutefois que ces mesures constituent une protection supplémentaire et ne dispensent pas d’installer les correctifs PHP.
L’intelligence artificielle a accéléré les recherches
Cette affaire illustre aussi l’évolution des outils de cybersécurité. Wiz explique avoir utilisé des modèles d’intelligence artificielle pour analyser les défauts et rendre praticable un travail d’exploitation particulièrement complexe.
Selon l’entreprise, l’IA a réduit le temps nécessaire pour développer et adapter des démonstrations fonctionnelles. Cette accélération aide les défenseurs à identifier des problèmes anciens, mais elle peut également réduire les obstacles techniques rencontrés par des attaquants.
La découverte d’une faille et la disponibilité d’un correctif ne constituent donc que deux étapes. La protection dépend ensuite de son déploiement sur les serveurs concernés.
Que faire lorsqu’on possède un site web ?
Pour un propriétaire de site WordPress, la première vérification est accessible dans Outils → Santé du site → Informations → Serveur. La version de PHP y est indiquée. Le panneau d’administration de l’hébergement peut également fournir cette information.
La démarche prioritaire consiste à :
- Demander à l’hébergeur de confirmer l’application des correctifs pour les deux CVE.
- Faire mettre à jour PHP si l’installation reste vulnérable.
- Vérifier après intervention que le site, les formulaires et les fonctions essentielles fonctionnent correctement.
Si la correction immédiate est impossible, CERT-EU recommande d’envisager l’isolement des applications exposées à Internet jusqu’à l’installation et à la vérification du correctif. Les mesures temporaires de configuration réduisent certains risques, mais ne corrigent pas complètement les vulnérabilités.
Pour les entreprises comme pour les petits éditeurs, la question à poser est précise : « La version de PHP qui exécute mon site contient-elle les correctifs de PHP2Shell ? » Car un site qui continue de fonctionner normalement n’apporte pas, à lui seul, la réponse.
