PHP2Shell expliqué aux dirigeants : votre site est-il exposé ?

PHP2Shell désigne deux failles critiques de PHP, le langage qui fait tourner WordPress et une bonne partie des sites d'entreprise : un attaquant peut exécuter son propre code sur votre serveur, sans identifiant. Les correctifs sont sortis le 21 octobre 2026 (PHP 8.2.35, 8.3.36, 8.4.27 et 8.5.12), avancés d'un jour parce que les détails avaient fuité (avis de sécurité PHP). Amazon avait déjà vu une première tentative d'attaque le 17 octobre (AWS) et les attaques se sont généralisées depuis (watchTowr). Le défaut se trouve dans PHP, pas dans WordPress, Laravel ou Symfony, si bien que toute version de PHP entre la 5.4 (2012) et la 8.5 est concernée, quel que soit le logiciel posé dessus. Cet article ne s'adresse pas à celui qui applique le correctif mais à celui qui décide : êtes-vous exposé, et que faut-il exiger de vos prestataires ?

---

L'image à retenir : le moteur et la carrosserie

PHP, c'est le moteur ; WordPress, Laravel, Symfony, Drupal ou Magento, c'est la carrosserie. D'une marque à l'autre, la ligne et les finitions changent, mais des milliers de modèles partagent le même moteur, et c'est lui qui a un défaut. Votre voiture a beau être bien construite et fraîchement repeinte, si ce moteur n'a pas été révisé depuis le 21 octobre, elle est exposée.

Voilà pourquoi cette faille dépasse de loin la « faille d'une extension WordPress » à laquelle on est habitué. Dans la configuration la plus risquée, l'attaque aboutit avant même que le code de votre application ne s'exécute, et une application bien écrite n'y change donc rien.

Faut-il s'inquiéter ? Trois questions à se poser

1. Avons-nous quelque chose qui tourne sur PHP ? Un site vitrine, une boutique, un portail client, un intranet ou un outil interne suffisent.
2. Est-ce joignable depuis internet ? C'est le cas de tout site public, beaucoup moins d'un outil réservé au réseau du bureau ou au VPN.
3. PHP a-t-il été mis à jour depuis le 21 octobre ? Oui aux deux premières et pas de réponse à la troisième : c'est urgent.

Repérer PHP sans équipe technique

• Le logiciel acheté ou commandé. WordPress, WooCommerce, Drupal, Joomla, Magento (Adobe Commerce), PrestaShop et Moodle tournent tous sur PHP, comme les applications sur mesure écrites avec Laravel, Symfony, CodeIgniter, CakePHP ou Yii, dont le nom figure en général sur le devis, la facture ou le document de livraison de l'agence.
• Les adresses des pages. Une adresse qui se termine par .php ou une connexion en /wp-admin trahit PHP.
• Le panneau d'hébergement. Chez un hébergeur qui fournit cPanel, Plesk ou équivalent, un réglage « Version PHP » ou « MultiPHP » confirme PHP et affiche la version utilisée.
• Chez les hébergeurs français courants. En hébergement mutualisé OVHcloud, la version de PHP apparaît dans l'espace client, sur la fiche de l'hébergement ; chez o2switch, elle se règle dans cPanel. Si vous avez un accès à ces espaces, vous pouvez la lire vous-même en deux minutes, sans rien modifier.
• Les en-têtes HTTP. Un outil gratuit de vérification des en-têtes montre parfois une ligne X-Powered-By: PHP/8.1.2, mais beaucoup de serveurs la masquent et son absence ne prouve rien.
• La question directe. Seule compte la version exacte, communiquée par écrit par votre hébergeur ou votre prestataire.

Pour Shopify, Wix ou Salesforce, c'est l'éditeur qui corrige. Ne vous concerne que ce qui tourne sur un serveur géré par vous, par votre hébergeur ou par votre agence.

Dater votre outil pour estimer le risque

Faute de connaître la version aujourd'hui, regardez l'année de création de l'outil : s'il n'a jamais été mis à jour, il tourne encore sur le PHP de l'époque. Un outil entretenu sera plus récent, il s'agit donc d'une estimation, pas d'un diagnostic.

Repères de sortie : PHP 5.4 en mars 2012, 7.0 en décembre 2015, 7.4 en novembre 2019, 8.0 en novembre 2020, 8.1 en novembre 2021, 8.2 en décembre 2022, 8.3 en novembre 2023, 8.4 en novembre 2024 et 8.5 en novembre 2025.

C'est la quatrième ligne qui pose problème. Quantité de logiciels métier ont été livrés entre 2019 et 2022 puis laissés en l'état, or PHP 8.1 ne reçoit plus rien depuis fin 2025 : pas de bouton « mettre à jour », il faut une vraie montée de version. Nous expliquions déjà comment la planifier avant que cette faille ne la rende urgente.

Ce qu'il faut faire

1. Mettre PHP à jour (8.2.35, 8.3.36, 8.4.27, 8.5.12 ou plus) puis le redémarrer, faute de quoi la mise à jour installée ne protège rien.
2. En PHP 8.1 ou plus ancien, se procurer un paquet corrigé auprès de la distribution Linux ou d'un éditeur de support, ou monter de version. D'après PHP, aucun réglage ne suffit à se protéger complètement.
3. Si rien de tout cela n'est possible cette semaine, retirer le site d'internet ou en restreindre l'accès. Cloudflare a activé des règles de filtrage pour tous ses clients, y compris en offre gratuite, et AWS en a publié d'équivalentes ; votre prestataire peut aussi couper une fonction de PHP exploitée par les attaques (session.upload_progress). Ce sont des pansements : ils ne remplacent pas la mise à jour.

Un hébergeur WordPress infogéré a très probablement déjà fait le nécessaire. Exigez tout de même une confirmation écrite.

Avez-vous été touché ?

Rien ne se verra sur le site, puisque l'attaque cherche justement à passer inaperçue. Demandez à votre hébergeur ou à votre développeur de fouiller les journaux du serveur web à partir du 17 octobre, et non du 21, à la recherche de requêtes contenant PHP_SESSION_UPLOAD_PROGRESS, le marqueur publié par AWS. Qu'il vérifie aussi les fichiers modifiés depuis cette date sans déploiement, les processus inconnus et les comptes administrateur apparus dans le back-office. Restent les signaux indirects : alerte de l'hébergeur pour abus ou trafic anormal, visiteurs redirigés vers un autre site, e-mails partis de votre domaine à votre insu.

Ne rien trouver ne prouve pas qu'il ne s'est rien passé. Un site non corrigé, public et qui accepte des envois de fichiers entre le 17 octobre et sa mise à jour justifie, par prudence, de changer les mots de passe et clés d'API stockés sur le serveur : base de données, paiement, envoi d'e-mails, comptes cloud.

Et si des données personnelles ont pu fuiter ?

C'est la question que les dirigeants oublient. Si le serveur compromis contenait des données personnelles (fichier clients, comptes utilisateurs, candidatures, commandes), le RGPD impose de notifier la CNIL dans les 72 heures après avoir pris connaissance de la violation, sauf si elle ne présente pas de risque pour les personnes concernées. Le délai court à partir du moment où vous savez, pas à partir du jour de l'attaque : documentez donc ce que vous avez vérifié, quand, et avec qui, même si vous concluez qu'il n'y a pas eu de fuite. Votre DPO, ou à défaut votre conseil juridique, tranche sur la notification.

Le message à envoyer à votre prestataire

Bonjour, suite aux failles PHP2Shell (CVE-2026-109618 et CVE-2026-109619), pouvez-vous me confirmer pour chacun de nos sites et outils : 1) la version exacte de PHP en production, 2) la date de sa mise à jour vers une version corrigée (8.2.35, 8.3.36, 8.4.27, 8.5.12 ou plus) et si PHP a bien été redémarré, 3) si les journaux depuis le 17 octobre contiennent des requêtes avec PHP_SESSION_UPLOAD_PROGRESS. Si un site tourne en PHP 8.1 ou plus ancien, que proposez-vous et dans quel délai ? Merci.

Ce que nous faisons, et ce que nous ne faisons pas

PHP2Shell ne touche pas nos propres produits, écrits en Go et en Python. Pour les vôtres, nous proposons :

• un audit de code à 2 500 € forfaitaires : ce qui tourne où, dans quelles versions, ce qui est exposé à internet, et l'ordre des travaux, chemin de mise à jour compris ;
• la montée de version ou la reprise d'un outil bloqué sur un vieux PHP que plus personne ne maintient, à partir de 800 € par jour, puis une maintenance à partir de 400 € par mois, pour que la prochaine faille se règle par une simple mise à jour.

Nous ne sommes pas une équipe de réponse à incident : au moindre signe d'intrusion, appelez d'abord votre hébergeur et un spécialiste. Nous intervenons ensuite pour reconstruire proprement et tenir l'ensemble à jour.

À lire aussi : fin de support PHP, Symfony, AngularJS : le plan d'action, la tierce maintenance applicative, et notre page sécurité.