Qu’est-ce que PHP2Shell et qui est concerné ?
PHP2Shell désigne deux vulnérabilités, CVE-2026-109618 et CVE-2026-109619. Toutes deux obtiennent 9,2 sur 10 sur l’échelle CVSS 4.0 et permettent l’exécution de code à distance : un attaquant peut faire tourner ses propres instructions sur votre serveur (php.net).
Elles touchent presque toutes les installations PHP qui servent des pages web : PHP-FPM, Apache avec mod_php, php-cgi, FrankenPHP et LiteSpeed. Selon l’avis officiel, le risque est plus élevé avec mod_php. Le projet précise qu’il n’existe pas de mesure d’atténuation complète et que la mise à jour est la seule option sûre (php.net).
Cloudflare a indiqué avoir observé du trafic d’attaque visant ces failles et avoir activé des règles de protection dans son pare-feu pour toutes les offres, y compris l’offre gratuite, environ neuf heures avant leur divulgation (Cloudflare). Ce pare-feu aide, mais il ne remplace pas la mise à jour.
Quelles versions de PHP sont prises en charge aujourd’hui ?
| Version | Support actif jusqu’au | Correctifs de sécurité jusqu’au | État en octobre 2026 |
|---|---|---|---|
| 8.5 | 31/12/2027 | 31/12/2029 | Active |
| 8.4 | 31/12/2026 | 31/12/2028 | Active |
| 8.3 | 31/12/2025 | 31/12/2027 | Sécurité uniquement |
| 8.2 | 31/12/2024 | 31/12/2026 | Sécurité uniquement, fin en décembre |
| 8.1 ou antérieure | Terminé | Terminé | Aucun correctif du projet PHP |
Source : php.net, versions prises en charge. Chaque version bénéficie de deux ans de support actif puis de deux ans de correctifs de sécurité.
La communauté a publié quelques correctifs minimaux pour 7.4, 8.0 et 8.1, et certains fournisseurs proposent un support étendu. Ce sont des solutions de transition, pas une raison de rester sur ces versions.
Combien de sites utilisent une ancienne version ?
Plus qu’on ne le croit. En janvier 2026, WordPress a publié les versions de PHP utilisées par ses installations : 22,2 % étaient encore sur PHP 7.4 et 27,3 % sur PHP 8.2 (WordPress). En ajoutant 8.1 et les versions antérieures, près de la moitié des sites WordPress de l’époque tournaient sur des versions qui ne recevaient plus de correctifs. WordPress recommande PHP 8.3 et, depuis la version 7.0, exige au minimum PHP 7.4.
Sur l’ensemble du web, W3Techs estime que PHP est utilisé par 69,2 % des sites dont le langage serveur est identifiable, et que 34,3 % d’entre eux utilisent encore PHP 7 ou PHP 5 (W3Techs).
Comment savoir quelle version de PHP utilise mon site ?
- Dans WordPress, allez dans Outils > Santé du site > Infos > Serveur. La version de PHP y figure.
- Dans cPanel, cherchez Sélectionner une version de PHP ou MultiPHP Manager.
- Si vous n’avez pas accès, demandez à votre hébergeur : « Quelle version exacte de PHP utilise mon site et intègre-t-elle le correctif du 21 octobre 2026 ? ».
Vérifiez le numéro complet. Par exemple, 8.3.36 est corrigée, 8.3.30 ne l’est pas.
Que faire si ma version est obsolète ?
- Faites une sauvegarde complète (fichiers et base de données) et conservez-la hors du serveur.
- Testez la nouvelle version sur une copie du site avant de la changer sur le site en ligne. Les grands sauts, comme de 7.4 à 8.3, peuvent casser d’anciennes extensions ou d’anciens thèmes.
- Mettez à jour WordPress, le thème et les extensions avant de changer de PHP, car les versions récentes sont en général les compatibles.
- Changez la version de PHP et vérifiez les pages clés : accueil, formulaires, panier et tableau de bord.
- En cas de problème, revenez à la version précédente depuis le même panneau et corrigez l’extension ou le thème en cause.
Si votre site est en 8.2 et fonctionne bien, passez dès maintenant à 8.2.35 et prévoyez la migration vers 8.3 ou 8.4 avant la fin de l’année.
Qu’est-ce qui peut encore exposer mon site ?
La version de PHP n’est qu’une partie du problème. Sur les sites WordPress, la plupart des vulnérabilités publiées chaque année se trouvent dans les extensions et les thèmes, pas dans le cœur. Voici les risques que l’OWASP Top 10 de 2025 classe parmi les plus courants dans les applications web (OWASP) :
- Extensions, thèmes et bibliothèques présentant des failles connues (défaillances de la chaîne d’approvisionnement logicielle). Une extension abandonnée peut ne jamais être corrigée.
- Mots de passe faibles et comptes sans double authentification (défaillances d’authentification).
- Formulaires qui acceptent n’importe quel fichier, ce qui permet d’envoyer du code sur le serveur.
- Injection SQL et XSS, quand le code ne valide pas ce que saisit le visiteur.
- Configuration non sécurisée, comme l’affichage des erreurs à l’écran ou des droits de fichiers trop ouverts.
Liste de vérification pour votre site
- Version de PHP corrigée (8.5.12, 8.4.27, 8.3.36 ou 8.2.35 ou ultérieure) et plan pour quitter 8.2 avant le 31/12/2026.
- Sauvegardes automatiques hors du serveur, avec une restauration testée.
- Extensions et thèmes à jour. Supprimez ceux que vous n’utilisez pas et ceux qui n’ont pas été mis à jour depuis plus d’un an.
- N’installez jamais d’extensions ou de thèmes « nulled » (versions payantes piratées).
- Double authentification (2FA) pour les administrateurs, mots de passe uniques et anciens comptes supprimés.
- Un pare-feu applicatif web devant le site, comme celui de Cloudflare ou de votre hébergeur.
- Erreurs PHP masquées en production, exécution de PHP bloquée dans le dossier des téléversements et éditeur de fichiers de WordPress désactivé.
- Une personne chargée d’appliquer les correctifs critiques en moins de 24 heures.
En résumé
- PHP2Shell désigne deux failles critiques qui permettent d'exécuter du code sur le serveur sans se connecter.
- Les versions corrigées sont 8.5.12, 8.4.27, 8.3.36 et 8.2.35.
- PHP 8.2 ne reçoit plus de correctifs après le 31 décembre 2026, et 8.1 ou antérieures n'en reçoivent déjà plus.
- Sauvegardez, testez sur une copie du site, puis mettez à jour.
- Extensions, mots de passe et formulaires comptent autant que la version de PHP.
Questions fréquentes
Mon site est-il en danger si j'utilise WordPress ?
Si le serveur utilise une version de PHP sans le correctif d'octobre 2026, oui, comme tout autre site en PHP. WordPress n'est pas la faille, mais il fonctionne sur PHP.
Mon hébergeur met-il PHP à jour tout seul ?
Cela dépend du fournisseur. Beaucoup appliquent les correctifs au sein d'une même version (de 8.3.30 à 8.3.36), mais ne changent pas de version majeure (de 7.4 à 8.3) sans votre accord, car cela peut casser le site.
Une extension de sécurité suffit-elle ?
Elle aide à détecter et bloquer des attaques, mais elle ne corrige pas une faille de PHP sur le serveur. La mise à jour reste nécessaire.
Mettre à jour PHP rend-il le site plus rapide ?
Les nouvelles versions sont en général plus efficaces, mais la différence dépend du site. La raison principale de mettre à jour reste la sécurité.
Que se passe-t-il si je ne quitte pas PHP 8.2 avant 2027 ?
Le site continuera de fonctionner, mais ne recevra plus de correctifs. Toute faille découverte ensuite restera ouverte.
Réponses de l'équipe AiDo CreativeSupport informatique
Assistance, assemblage de PC et Microsoft 365, en tant que Microsoft Partner et intégrateurs OEM.
Voir le service
