PHP2Shell : de quoi s'agit-il et comment protéger votre site PHP

Informations vérifiées le 26 octobre 2026 d’après les notes de version de PHP, les rapports des chercheurs et des éditeurs de sécurité. Nous mettrons à jour cet article lors de la prochaine version de PHP.

Si votre site fonctionne sous PHP, mettez PHP à jour aujourd’hui. C’est la version courte de cet article.

Le 21 octobre 2026, le projet PHP a publié des correctifs pour deux failles critiques de sécurité dans PHP, connues sous le nom de PHP2Shell. Elles permettent à un attaquant de prendre le contrôle d’un serveur web depuis Internet, sans identifiant ni mot de passe. Les attaques avaient déjà commencé avant la publication du correctif.

Selon W3Techs, PHP est utilisé par 69,2 % des sites dont la technologie serveur est connue, dont WordPress, WooCommerce, Magento, Drupal, Joomla, Laravel et la majorité des sites PHP sur mesure. Ce n’est donc pas un problème isolé, mais une faille qui touche une grande partie du web.

Pour les propriétaires de site : PHP2Shell expliqué simplement

Pas technique ? Cette partie vous concerne. PHP est le logiciel sur votre serveur web qui fait fonctionner votre site, comme le moteur d’une voiture. Si votre site utilise WordPress, WooCommerce, Magento, Drupal, Joomla ou Laravel, il fonctionne avec PHP.

PHP2Shell désigne deux failles dans ce moteur. Un inconnu peut envoyer une requête spécialement conçue à votre site et prendre le contrôle du serveur. Aucun mot de passe ni compte n’est nécessaire. La faille ne vient pas de votre thème ou de vos extensions : les mettre à jour ne résout pas le problème. Seule une mise à jour de PHP lui-même le corrige.

Une fois entré, un attaquant peut lire les mots de passe et clés stockés sur le serveur, accéder à vos données clients, modifier votre site ou installer une porte dérobée pour revenir plus tard. Les premières attaques ont commencé avant même la publication du correctif : il ne faut pas attendre le mois prochain.

Ce qu’il faut faire aujourd’hui :

1. Posez une question à votre prestataire ou hébergeur : « Notre version de PHP corrige-t-elle PHP2Shell, et PHP a-t-il été redémarré ensuite ? » Demandez une réponse écrite, oui ou non.
2. Si la réponse est non ou « pas sûr », demandez la correction aujourd’hui. Si votre site utilise une version ancienne de PHP (8.1 ou antérieure), il n’existe pas de correctif prêt à l’emploi : il faut prévoir une montée de version sans attendre.
3. Si c’est déjà corrigé, demandez-leur de vérifier le serveur pour détecter toute trace d’attaque depuis le 17 octobre et de changer les mots de passe et clés qui y sont stockés.
4. Si personne ne gère votre serveur ou si vous n’obtenez pas de réponse, faites-vous aider dès maintenant. Chaque jour où un site non corrigé reste en ligne augmente le risque d’intrusion.

Si votre boutique fonctionne sur Shopify ou une autre plateforme hébergée, vous n’avez rien à faire : c’est la plateforme qui gère les serveurs, pas vous.

En résumé

• Mettez PHP à jour vers la version 8.5.12, 8.4.27, 8.3.36 ou 8.2.35 (ou ultérieure), puis redémarrez PHP-FPM, Apache ou tout worker PHP en fonctionnement. Mettre à jour WordPress, Magento ou vos extensions ne met pas à jour PHP.
• Sur PHP 8.1 ou antérieur, il n’existe pas de mise à jour officielle prête à l’emploi. Passez à une version prise en charge, ou utilisez un hébergeur ou un paquet Linux qui a intégré les deux correctifs.
• Impossible de mettre à jour aujourd’hui ? Activez les règles PHP2Shell de votre pare-feu web et les réglages PHP du point 4 ci-dessous. Cela réduit le risque, mais ne garantit pas la sécurité.
• Après la mise à jour, considérez que les secrets stockés sur le serveur ont pu être exposés et recherchez des signes d’attaque à partir du 17 octobre 2026.

Qu’est-ce que PHP2Shell ?

PHP2Shell est le nom donné par les chercheurs à deux failles du moteur PHP, ainsi qu’au script d’exploitation qui les combine. Les failles ne concernent ni votre thème, ni vos extensions, ni votre code : elles touchent PHP lui-même, le logiciel qui exécute votre site sur le serveur.

C’est ce qui rend la situation grave. Les chercheurs de Wiz précisent qu’une simple application « Hello World » sur une version vulnérable de PHP peut être exposée. Pour les serveurs Apache avec mod_php, PHP indique qu’un exploit fonctionne « avant même l’exécution du code applicatif ». Votre site peut donc être à risque même si votre code est irréprochable.

En résumé : lorsqu’une requête fait que PHP manque de mémoire (ou rencontre une autre erreur fatale au mauvais moment), PHP interrompt la requête brutalement et, à certains endroits, ne nettoie pas correctement. Des données incomplètes, ou qui auraient dû être supprimées, restent en mémoire et PHP les considère ensuite comme valides, parfois lors du traitement de la requête suivante sur le même worker. Un attaquant peut déclencher ce comportement volontairement via des requêtes d’envoi de formulaire spécialement conçues, même sur une page qui n’utilise jamais d’upload, et ainsi exécuter ses propres commandes.

RCE signifie exécution de code à distance : une personne sur internet peut exécuter son propre code sur votre serveur. OOM signifie manque de mémoire. PHP attribue à ces deux failles la note de 9,2 sur 10 (critique) selon la nouvelle échelle CVSS 4.0. La National Vulnerability Database américaine utilise l’ancienne échelle CVSS 3.1 et les note 9,8 (critique) et 8,1 (élevé) ; vous pouvez donc rencontrer ces chiffres également. Le nom PHP2Shell décrit le résultat : d’un site PHP ordinaire à un « shell », c’est-à-dire un accès complet aux commandes du serveur.

Que peut réellement faire un attaquant ?

• Exécuter des commandes sur votre serveur web, sans identifiant ni mot de passe.
• Lire des secrets dans la mémoire du serveur. Wiz cite « mots de passe, jetons d’authentification, clés API et certificats ». L’attaquant n’a même pas besoin d’exécuter du code sur votre serveur, ce qui rend l’attaque discrète et difficile à détecter.
• Utiliser ces secrets pour accéder à votre base de données, aux données clients et aux comptes de prestataires de paiement.
• Installer une porte dérobée (un « web shell ») pour revenir plus tard, ou modifier et défigurer votre site.

Comment PHP2Shell est apparu

Les failles ont été signalées en août, gardées confidentielles pendant que PHP préparait un correctif, puis la publication a été avancée après la fuite des numéros de vulnérabilité.

Selon la PHP Foundation, les deux numéros CVE ont fuité le 20 octobre sans détails techniques, bien qu’une vidéo publiée par erreur par une société de recherche ait révélé quelques informations limitées. La Fondation précise aussi qu’un développeur principal de PHP avait identifié les premiers signes du problème de mémoire lors d’un audit en 2024, mais qu’il n’avait pas été corrigé à ce moment-là.

Pourquoi cette faille a été traitée aussi vite

L’IA a joué un rôle majeur dans la découverte. Wiz indique avoir utilisé ses propres modèles (Wiz Atlas), Gemini 4 Argon de Google et GPT-5.6 Sol d’OpenAI, et qu’« un seul chercheur a accompli en une semaine ce qui aurait pris des mois à une équipe de pointe ». L’équipe Codex Security d’OpenAI et Calif sont également crédités sur le site PHP2Shell avec Wiz.

Les attaquants disposent des mêmes outils. L’équipe de veille d’Amazon prévient que l’IA réduit le coût pour transformer un correctif en exploit fonctionnel, donc « davantage d’acteurs peuvent agir en quelques heures, voire minutes ». Pour les failles critiques sur des systèmes exposés à Internet, elle recommande : « mesurez les délais de correction et de mitigation en heures ».

Qui est concerné par PHP2Shell ?

Les versions officielles de PHP concernées vont de 8.2 à 8.5 ; les versions 7.4, 8.0 et 8.1 n’ont reçu que des correctifs sur le code source. Les chercheurs estiment que les versions touchées remontent à PHP 5.4 et que presque toutes les versions de PHP sont concernées par au moins l’une des deux failles. Si votre site, boutique ou application web fonctionne sous PHP et que vous n’avez pas mis à jour PHP depuis le 21 octobre 2026, considérez que vous êtes concerné.

La liste de ProjectDiscovery recense une vingtaine de logiciels PHP à longue durée d’exécution à vérifier. Tout ce qui fonctionne sous PHP est concerné, notamment :

• WordPress et WooCommerce, Magento / Adobe Commerce, Laravel, Drupal et Joomla
• Moodle, Nextcloud et MediaWiki
• Outils d’administration comme phpMyAdmin, la messagerie web Roundcube et WHMCS
• Panneaux d’hébergement comme cPanel et Plesk
• Équipements réseau intégrant PHP, des pare-feux (pfSense, OPNsense) aux systèmes téléphoniques (FreePBX) et outils de supervision (Zabbix, Nagios XI). Les éditeurs publient leurs propres bulletins ; celui de HPE pour ClearPass Policy Manager en est un exemple.

L’ampleur est considérable. Selon les chiffres publiés le jour du correctif, VulnCheck a recensé PHP sur 2 608 039 hôtes exposés à internet sur les 30 derniers jours, et estime que 99,998 % d’entre eux sont vulnérables ou probablement vulnérables. Plus de 1,1 million, soit environ 42 %, utilisent des versions PHP en fin de vie sans correctif officiel, et environ 27 % tournent sous PHP 7.3 ou antérieur. De nombreux hôtes masquent leur version de PHP, donc une partie de ce décompte repose sur l’estimation de VulnCheck.

Qui n'est pas concerné

• Les plateformes entièrement hébergées comme Shopify, où c'est la plateforme qui gère les serveurs, pas vous. Tout blog WordPress ou outil PHP que vous exécutez à côté reste à vérifier.
• Sites sans PHP sur le serveur : Node.js, Next.js, Python ou simple HTML statique.
• Serveurs déjà mis à jour vers les versions corrigées ci-dessous et redémarrés depuis. (Surveillez le troisième bug mentionné plus bas.)

Versions de PHP corrigées

Si vous utilisez PHP 8.2, son support de sécurité prend fin le 31 décembre 2026. Prévoyez dès maintenant la migration vers 8.4 ou 8.5 pour éviter deux migrations successives. Nous analysons la question plus largement dans PHP est-il toujours adapté à l’e-commerce.

Les attaquants exploitent-ils déjà PHP2Shell ?

Oui. Les tentatives d’attaque ont commencé avant la publication du correctif.

• Quatre jours d'avance : Les honeypots MadPot d'Amazon (serveurs leurres conçus pour attirer les attaquants) ont enregistré une tentative d'exploitation PHP2Shell datée du 17 octobre 2026, soit quatre jours avant la divulgation publique.
• Avant l'heure de publication : Amazon signale des exploits de preuve de concept dès 02h00 UTC le 21 octobre, douze heures avant la diffusion des versions corrigées, puis d'autres dans les heures suivantes. Amazon fait désormais état de « tentatives d'exploitation généralisées dans la nature ».
• Scan automatisé : VulnCheck a observé des scanners utilisant l'user-agent php2shell-scan/109618, et une tentative depuis une adresse IP en Chine pour déposer un web shell via un fichier de session. Cette tentative a échoué.
• Faux exploits : de faux dépôts de preuve de concept circulent sur GitHub. N'exécutez jamais de code d'exploitation téléchargé sur un serveur important.

Certaines organisations ont préféré mettre leurs sites hors ligne sans attendre. Selon les articles de presse recensés sur la page Wikipédia PHP2Shell, de nombreuses organisations européennes ont mis leurs sites hors ligne sur recommandation du CERT-EU et du NCSC britannique, et la NSA américaine a conseillé de couper l’accès si la mise à jour immédiate n’était pas possible. La Finlande a suspendu ses services publics web, et l’Internet Archive a brièvement fermé.

Un troisième bug, à moindre risque (23 octobre)

Deux jours après le correctif principal, PHP a publié un avis d’information concernant une faille liée, CVE-2026-115560, dans la fonctionnalité de suivi de progression d’upload de session. Selon Cloudflare, elle touche aussi les versions corrigées, y compris 8.5.12. PHP la qualifie de « vecteur RCE peu probable » nécessitant une configuration de session inhabituelle. En attendant la prochaine version régulière de PHP, il est conseillé de définir session.upload_progress.enabled=0.

Comment protéger votre site PHP : cinq étapes

Mettre à jour PHP est la seule solution complète. L’avis de sécurité PHP est clair : « Il n’existe aucune mesure de mitigation complète, la mise à jour est la seule option sûre. » Suivez ces étapes dans l’ordre.

Étape 1 : Identifiez tous les environnements où PHP s'exécute

Dressez la liste de tous les serveurs, sites et outils que vous possédez et qui utilisent PHP. N'oubliez pas :

• Les environnements de préproduction et de test de votre site
• Les anciens sites de campagne ou pages d'atterrissage réalisés par une agence
• Les outils d'administration comme phpMyAdmin ou la messagerie web
• Les conteneurs Docker construits à partir d'une ancienne image php:
• Les panneaux d'hébergement et équipements réseau

Les sites oubliés sont faciles à négliger et rarement corrigés. Profitez-en pour vérifier que le port 9000 de PHP-FPM n'est pas accessible depuis Internet : ProjectDiscovery signale que les images Docker officielles de php-fpm écoutent sur ce port sur toutes les interfaces réseau. Si vous avez hérité d'une base de code ou d'un serveur mal documenté, notre cadre d'audit PHP legacy est un bon point de départ.

Étape 2 : Vérifiez la version de PHP

• Hébergement mutualisé ou cPanel : consultez votre panneau d'hébergement sous « Sélectionner la version de PHP » ou « MultiPHP Manager ».
• Serveur dédié (VPS) : exécutez php -v et php-fpm -v sur le serveur. Sur certains systèmes, la commande FPM inclut la version, par exemple php-fpm8.3 -v.
• WordPress : allez dans Outils → Santé du site → Informations → Serveur.

Comparez avec le tableau des versions corrigées ci-dessus. Si votre hébergeur ou distribution Linux rétroporte les correctifs, vérifiez le journal des modifications du paquet pour les deux CVE, et non seulement le numéro de version.

Étape 3 : Mettez PHP à jour puis redémarrez-le

Installez la version corrigée, puis redémarrez Apache, PHP-FPM, LiteSpeed et tout worker PHP en tâche de fond. Les chercheurs recommandent d'« installer une version corrigée de PHP sur chaque environnement d'exécution, puis de redémarrer ». Tant que vous n'avez pas redémarré, l'ancienne version de PHP continue de traiter les requêtes. Si vous utilisez Apache avec mod_php, commencez par ces serveurs : PHP les considère comme les plus exposés.

Mettre à jour WordPress, Magento ou vos extensions ne met pas à jour PHP. PHP est un logiciel distinct sur le serveur. Pour Docker, reconstruisez votre image à partir d'une base php: corrigée et redéployez.

Étape 4 : Si la mise à jour n'est pas possible aujourd'hui

Ces mesures réduisent le risque temporairement. L’avis de sécurité PHP précise qu’elles « réduisent l’exposition à certains vecteurs d’attaque mais ne sécurisent pas l’installation ». Certaines peuvent perturber les uploads, vérifiez donc votre site après chaque modification.

• Activez les règles PHP2Shell de votre pare-feu web. Cloudflare a déployé les règles automatiquement sur tous les forfaits avec son WAF, y compris l’offre gratuite. Fortinet mentionne la protection FortiWeb et FortiGate dans son alert d’épidémie. Pour la faille du 23 octobre, la règle Cloudflare ne couvre pas les sites ayant renommé session.upload_progress.name.
• Désactivez le suivi de progression des envois : définissez session.upload_progress.enabled=0 dans php.ini ou la configuration du pool PHP-FPM, puis redémarrez chaque worker. Le paramétrage via ini_set() ou un fichier .user.ini ne fonctionne pas ici.
• Réduisez la taille des requêtes : fixez post_max_size à 8M si le site n'accepte pas d'envois, ou 32M s'il en accepte. Amazon recommande aussi de bloquer les envois multipart sur les serveurs non corrigés.
• Sur PHP 8.5, définissez aussi fatal_error_backtraces=0 et redémarrez chaque worker.
• Mettez le site hors ligne ou protégez-le par une authentification s'il est sensible. Plusieurs services publics ont appliqué cette mesure.

Étape 5 : Après la mise à jour, vérifiez si vous avez été touché

Si le serveur était accessible depuis Internet avant la mise à jour, supposez que des secrets en mémoire ont pu fuiter. Remontez au moins jusqu'au 17/10/2026, date du premier signalement par Amazon.

• Changez les mots de passe des bases de données, les clés API, les clés de passerelle de paiement, les mots de passe SMTP et les clés de signature de session (par exemple les « salts » WordPress ou la clé de chiffrement Magento avec un développeur, si cela peut se faire en sécurité).
• Recherchez de nouveaux comptes administrateurs inconnus, des fichiers PHP nouveaux ou modifiés (notamment dans les dossiers d'envoi ou de session) et de nouvelles tâches planifiées (cron jobs).
• Examinez les journaux de requêtes pour les uploads POST contenant PHP_SESSION_UPLOAD_PROGRESS (Amazon), et pour les requêtes multipart suivies d’erreurs « Allowed memory size of … bytes exhausted », d’erreurs 500 répétées ou de crashs de workers PHP (Wiz).
• Surveillez la présence de cookies PHPSESSID anormalement volumineux ou mal formés dans les réponses (Wiz), et du texte PWNED:: dans les réponses ou fichiers de session (VulnCheck).
• Recherchez des processus inconnus et des connexions sortantes inattendues depuis le serveur.

Si vous constatez une anomalie, faites appel à un expert avant toute intervention, afin de préserver les preuves.

À retenir

PHP2Shell est l’un des problèmes de sécurité web les plus graves de ces dernières années. Il touche PHP lui-même, il est accessible depuis internet sans authentification, et les attaques ont commencé avant la publication du correctif.

La correction est simple : mettez PHP à jour, redémarrez-le, et vérifiez chaque serveur. Faites-le dès aujourd'hui. Profitez-en pour retirer tout ce qui fonctionne encore sur une version PHP en fin de vie. Si une application legacy entière vous bloque, nous avons documenté la migration d'un monolithe PHP vers Laravel sans gel des fonctionnalités.

Besoin d'aide pour corriger PHP2Shell ?

Nous gérons au quotidien des sites WordPress et WooCommerce, Magento, Laravel et PHP sur mesure. Nous pouvons recenser tous vos sites et serveurs PHP, mettre PHP à jour en toute sécurité et le redémarrer, configurer un pare-feu web, renouveler vos mots de passe et clés, vérifier la présence d'indices d'intrusion et migrer les anciens sites hors de PHP 7.x, 8.0 et 8.1 en fin de vie.

Contactez-nous ou écrivez à info@stathmosgroup.com ; nous commencerons par votre serveur le plus exposé.