Deux failles critiques ont été découvertes au cœur même de PHP, le langage qui fait tourner WordPress. Surnommées « PHP2Shell », elles permettent à un pirate de prendre le contrôle d’un serveur à distance, sans mot de passe.
Le correctif est sorti ce mercredi 21 octobre 2026 à 16h (heure de Paris). Tant que la version PHP de votre site n’est pas mise à jour, considérez qu’il est exposé.
Que s’est-il passé ?
Les deux failles portent les références CVE-2026-109618 et CVE-2026-109619. Elles sont notées 9,2 sur 10 en gravité (CVSS v4.0). Leur existence a fuité avant la date prévue, ce qui a forcé l’équipe PHP à accélérer.
| Date | Événement |
|---|---|
| 2024 | Un premier signe du problème est repéré lors d’un audit de sécurité de PHP, sans piste d’exploitation concrète à l’époque. |
| 11 – 24 août 2026 | Les chercheurs de Calif, OpenAI puis Wiz signalent à l’équipe PHP qu’il est possible d’exécuter du code à distance. |
| 20 octobre, vers 17h | Les références des failles circulent sur des forums et les réseaux sociaux, avec une date et une note erronées. |
| 20 octobre, 21h30 | PHP publie une pré-annonce et avance la sortie du correctif d’une journée. |
| 21 octobre, 16h | Sortie des versions corrigées de PHP. Le CERT-FR (ANSSI) publie une alerte le jour même. |
Heures données en heure de Paris.
Concrètement, une seule requête web bien construite peut suffire à exécuter du code sur le serveur. Les chercheurs ont aussi montré qu’on pouvait lire une partie de la mémoire du serveur, où peuvent traîner des mots de passe, des jetons de connexion ou des clés d’API.
Mon site WordPress est-il concerné ?
Oui, si votre serveur fait tourner une version de PHP non corrigée. La faille se trouve dans PHP lui-même, pas dans WordPress, un thème ou une extension. Un site parfaitement entretenu peut donc être vulnérable.
Sont concernés :
- Les CMS et frameworks PHP : WordPress, WooCommerce, PrestaShop, Drupal, Joomla, Magento, Laravel… Les chercheurs ont démontré une prise de contrôle sans authentification sur WordPress, Drupal et Joomla.
- Toutes les versions de PHP depuis la 5.4, soit plus de dix ans de versions.
- Toutes les configurations serveur courantes : PHP-FPM, Apache avec mod_php, php-cgi, FrankenPHP et LiteSpeed. Les serveurs Apache avec mod_php sont les plus exposés, l’attaque pouvant aboutir avec les réglages par défaut.
PHP fait tourner environ 7 sites web sur 10 dans le monde. C’est ce qui fait de PHP2Shell l’une des failles les plus sérieuses de ces dernières années.
Côté exploitation, les signaux divergent. Patchstack, spécialiste de la sécurité WordPress, signale des incidents d’exploitation dès le matin du 21 octobre. L’équipe PHP indique de son côté n’avoir identifié aucun exploit fonctionnel au moment de la sortie du correctif. Dans les deux cas, des attaques automatisées à grande échelle sont attendues dans les jours qui viennent.
Quelles versions de PHP sont corrigées ?
Les versions sûres sont PHP 8.5.12, 8.4.27, 8.3.36 et 8.2.35. Tout ce qui est antérieur est vulnérable.
| Votre version | Version corrigée | Ce qu’il faut faire |
|---|---|---|
| PHP 8.5 | 8.5.12 | Mettre à jour immédiatement |
| PHP 8.4 | 8.4.27 | Mettre à jour immédiatement |
| PHP 8.3 | 8.3.36 | Mettre à jour immédiatement |
| PHP 8.2 | 8.2.35 | Mettre à jour, puis prévoir le passage en 8.3 ou plus : la 8.2 arrive en fin de vie le 31 décembre 2026 |
| PHP 8.1 et antérieures | Aucune version officielle | Passer en PHP 8.2 minimum, ou demander à l’hébergeur s’il applique un correctif rétroporté |
Pour PHP 7.4, 8.0 et 8.1, l’équipe PHP a publié des correctifs minimaux à compiler soi-même. Ils s’adressent aux administrateurs de serveurs, pas aux propriétaires de sites en hébergement mutualisé.
Comment connaître la version PHP de mon site ?
Dans WordPress, la vérification prend 30 secondes :
- Connectez-vous à l’administration de votre site.
- Allez dans Outils > Santé du site.
- Ouvrez l’onglet Informations, puis la section Serveur.
- Lisez la ligne Version de PHP : comparez-la à la version corrigée de votre branche dans le tableau ci-dessus (par exemple 8.3.36 ou plus pour PHP 8.3).
Vous pouvez aussi trouver cette information dans l’espace client de votre hébergeur, généralement dans une rubrique « PHP » ou « Configuration ».
Que faire maintenant ?
La seule protection complète est la mise à jour de PHP. Ce qu’il faut faire dépend de votre type d’hébergement.
Vous êtes en hébergement mutualisé (OVHcloud, o2switch, Hostinger, PlanetHoster…)
C’est votre hébergeur qui installe le correctif sur ses serveurs. En général, il le fait lui-même pour les versions 8.2 à 8.5.
- Surveillez les e-mails, le blog ou la page de statut de votre hébergeur.
- Vérifiez dans quelques heures que la version de PHP a bien changé (voir ci-dessus).
- Si votre site tourne en PHP 8.1 ou plus ancien, passez en 8.3 ou 8.4 depuis votre espace client, après une sauvegarde.
- Sans nouvelles de votre hébergeur, contactez son support.
Vous gérez votre propre serveur (VPS, serveur dédié, conteneurs)
- Installez les paquets corrigés de votre distribution, ou PHP 8.5.12, 8.4.27, 8.3.36 ou 8.2.35 depuis php.net.
- Redémarrez PHP-FPM ou le serveur web : sans redémarrage, l’ancienne version reste en mémoire.
- Pour Docker, reconstruisez vos images à partir d’une image PHP corrigée.
- Si vous utilisez le dépôt Remi (rpms.remirepo.net), passez aux paquets de votre distribution ou compilez PHP : ce dépôt n’avait pas de mise à jour disponible le 21 octobre.
- Faites l’inventaire de tous vos sites, y compris les vieux sites oubliés, les préproductions et les outils internes.
Avant toute modification, faites une sauvegarde complète du site (fichiers et base de données). Après la mise à jour, naviguez sur le site en mode déconnecté pour vérifier que tout fonctionne.
Impossible de mettre à jour tout de suite ?
Ces mesures réduisent le risque, elles ne le suppriment pas. Le CERT-FR précise d’ailleurs qu’il ne les a pas lui-même validées. Le CERT-EU et le NCSC britannique vont plus loin : ils invitent à envisager la mise hors ligne des sites qui ne peuvent pas être corrigés rapidement.
1. Désactiver le suivi de progression des envois de fichiers. Dans le fichier php.ini :
session.upload_progress.enabled = OffAvec PHP-FPM, ajoutez aussi dans la configuration du pool :
php_admin_flag[session.upload_progress.enabled] = offCette mesure ne couvre qu’une seule des deux failles.
2. Filtrer les requêtes « multipart » avec un pare-feu applicatif (WAF). Le CERT-FR conseille de bloquer, ou au minimum de surveiller, les requêtes dont l’en-tête Content-Type est de type multipart. Attention : c’est ce format qu’utilisent les envois de fichiers, donc le blocage peut casser l’ajout de médias dans WordPress ou les formulaires avec pièce jointe.
3. Passer derrière Cloudflare. Cloudflare a déployé des règles de pare-feu contre les vecteurs d’attaque connus, y compris pour les comptes gratuits. C’est une protection d’appoint utile, pas un remplacement du correctif.
Méfiez-vous enfin des « outils de test » ou exploits téléchargeables qui circulent sur les réseaux : certains contiennent des logiciels malveillants.
Pourquoi cette faille fait date
Le code vulnérable était présent dans PHP depuis plus de dix ans. Il touche deux mécanismes que presque chaque requête utilise : la gestion de la mémoire et la gestion des erreurs. Un dépassement de la limite mémoire au mauvais moment pouvait laisser derrière lui des données à moitié initialisées, réutilisées ensuite par une autre requête.
Transformer ce défaut en attaque réelle demandait une chaîne d’étapes très complexe, à la limite de ce qu’un chercheur pouvait faire à la main. Selon Wiz, ce sont des modèles d’IA de pointe qui ont rendu l’exploitation praticable, un chercheur seul faisant en une semaine ce qui aurait demandé des mois à une équipe d’élite.
La leçon vaut pour tout le monde : l’IA accélère la découverte des failles, côté défense comme côté attaque. Le délai entre la publication d’un correctif et les premières attaques va continuer de se réduire. Mettre à jour vite devient la règle, plus l’exception.
FAQ
La mise à jour peut-elle casser mon site ?
Rester dans la même branche (de 8.3.x à 8.3.36, par exemple) n’apporte que des correctifs : le risque est très faible. Changer de branche (de 8.1 à 8.3) peut révéler des extensions ou un thème incompatibles. Dans ce cas, sauvegardez d’abord et testez si possible sur une copie du site.
Mon extension de sécurité WordPress me protège-t-elle ?
Pas de façon fiable. Sur certaines configurations, l’attaque aboutit avant même que WordPress ne se charge, donc avant que l’extension ne puisse agir. Un pare-feu placé devant le serveur (celui de l’hébergeur ou Cloudflare) est plus utile, mais seule la mise à jour de PHP protège complètement.
Comment savoir si mon site a été attaqué ?
L’attaque se joue au niveau de PHP, en dessous de WordPress : ses journaux peuvent ne rien montrer. Côté serveur, Wiz conseille de surveiller les erreurs de limite mémoire ou les erreurs 500 à répétition après des envois de formulaires inhabituels, ainsi que des cookies PHPSESSID anormalement longs. Côté site, restez attentif aux signes classiques : compte administrateur inconnu, fichiers PHP suspects, redirections étranges.
Dois-je changer mes mots de passe ?
Par prudence, oui, si votre site est resté exposé. La faille permet de lire une partie de la mémoire du serveur. Renouvelez les mots de passe administrateurs, celui de la base de données et les clés d’API utilisées par le site (paiement, envoi d’e-mails, etc.).
Que faire si je pense avoir été piraté ?
Passez le site en maintenance et prévenez votre hébergeur. Mettez PHP à jour, restaurez une sauvegarde saine antérieure à l’attaque, puis changez tous les accès. En cas de doute, faites-vous accompagner par un professionnel.
En résumé
PHP2Shell ne fera pas « tomber Internet », mais elle expose des millions de sites, dont une grande partie des sites WordPress. Trois réflexes suffisent : vérifier votre version de PHP, la mettre à jour (ou vous assurer que votre hébergeur l’a fait), puis contrôler que tout fonctionne.
0 commentaires