PHP2Shell : mettre à jour PHP, mode d'emploi

PHP2Shell est le nom donné par les sources de sécurité à deux vulnérabilités du moteur PHP lui-même, le langage qui fait tourner une grande partie du web, dont WordPress. Le nom s'est imposé chez le Centre canadien pour la cybersécurité (alerte AL26-026), chez Rapid7 et chez Bitsight. Aucune de ces sources ne parle de « Black October » : si vous avez croisé ce surnom, il ne désigne pas un nom officiel.

Les deux failles reçoivent un score de 9,2 sur 10 (échelle CVSS v4.0) de la part de l'équipe de sécurité PHP, selon la FAQ de Tenable. Des billets antérieurs à la publication évoquaient 10 sur 10, un écart relevé par IT-Connect : la valeur officielle est 9,2. En pratique, la différence ne change pas la conduite à tenir.

Que permettent concrètement ces failles ?

Elles portent sur la gestion de la mémoire de PHP. La première (CVE-2026-109618) vient d'une corruption provoquée par un manque de mémoire en cours de requête ; la seconde (CVE-2026-109619) d'un état de requête qui survit à la libération de sa mémoire et qu'une requête suivante peut réutiliser. Dans les deux cas, d'après l'avis du projet PHP, un attaquant sans authentification peut obtenir une exécution de code à distance. Le code s'exécute avec les droits du processus PHP, donc avec l'accès de votre site à ses fichiers et à sa base de données : vol de données, défiguration, porte dérobée (Malwarebytes).

Le risque est jugé le plus élevé avec Apache en mode mod_php, où une requête non authentifiée peut déclencher l'attaque avant même que le code de votre site ne s'exécute. Sont concernées toutes les installations qui servent des pages web : PHP-FPM, Apache avec mod_php, php-cgi, FrankenPHP et LiteSpeed (Help Net Security).

Les versions corrigées sont celles du 21 octobre 2026, selon l'avis du projet PHP confirmé par le Centre canadien :

Sources : php.net pour les versions et la fin de vie de la 8.2, IT-Connect pour les correctifs des branches 7.4 à 8.1, watchTowr pour l'absence de correctif en 7.3 et avant.

Mon PHP est ancien (7.4, 8.0, 8.1) : suis-je touché ?

Le projet PHP ne publie pas de version officielle pour ces branches, donc sans correctif de votre hébergeur ou de votre distribution, la réponse prudente est oui. D'après Sansec, le code vulnérable remonte à PHP 5.4, sorti en 2012. Wiz et d'autres évoquent « toutes les versions depuis PHP 5 » ; le projet PHP, lui, ne donne pas de plage de versions explicite, ce point reste donc à lire avec réserve. Ce qui compte pour vous : une branche sans mise à jour ne peut pas être « surveillée », elle doit être remplacée.

Combien de sites sont concernés ?

Pas de chiffre définitif, et il faut se méfier de ceux qui circulent. CybelAngel, à partir de statistiques Shodan du 20 octobre, compte environ 2,24 millions d'hôtes PHP exposés sur Internet, dont 59 % de ceux qui affichent leur version tournent sur des branches sans version officielle corrigée. Ce sont des hôtes, pas des sites : l'hébergement mutualisé en place plusieurs derrière une même adresse, et certaines distributions corrigent sans changer le numéro de version (CybelAngel).

Les sources se contredisent, et il vaut mieux le dire que choisir la version la plus rassurante ou la plus alarmiste :

• Exploitation signalée : Cloudflare a observé des premières attaques et déployé des règles de pare-feu, présentées comme temporaires (BleepingComputer). watchTowr dit avoir vu les deux failles exploitées le 21 octobre sur ses pièges à attaques (watchTowr). Amazon rapporte une tentative dès le 17 octobre, quatre jours avant la divulgation (Help Net Security).
• Pas d'exploitation confirmée : l'alerte du Centre canadien indiquait qu'aucune exploitation active n'était identifiée au moment de sa rédaction, et Rapid7 relevait des tentatives sans exploitation réussie observée.
• Des exploits publics, mais capricieux : plusieurs preuves de concept circulent, mais chacune ne marche que pour une combinaison précise de système, de version PHP et de serveur web (Rapid7). Sansec précise qu'elles ne fonctionnent pas sur une installation par défaut. Tenable avertit en outre que du code d'exploitation en circulation peut lui-même contenir un logiciel malveillant : ne téléchargez rien.

Le registre américain des failles activement exploitées (CISA KEV) ne listait pas ces deux CVE à la date de notre vérification, le 24 octobre ; cette vérification n'est pas exhaustive. Conclusion raisonnable : pas de panique, mais pas de délai. Une faille sans identifiant, avec des exploits publics et des attaques signalées, se corrige dans la semaine, pas dans le trimestre.

Trois méthodes, de la plus simple à la plus technique. Dans tous les cas, notez le numéro exact de version.

Avec WordPress : l'écran Santé du site

Dans l'administration, menu Outils puis Santé du site, onglet Infos, section Serveur : la ligne « Version de PHP » donne la valeur. C'est la méthode la plus sûre pour un non-technicien, sans rien installer.

Avec le panneau de votre hébergeur

La plupart des hébergeurs affichent la version dans leur espace client (rubrique PHP ou « Configuration PHP »). Chez Hostinger, la procédure indiquée par l'hébergeur est : hPanel, Sites web, Tableau de bord, puis « PHP Info » dans la barre latérale (page d'incident Hostinger).

Avec un fichier phpinfo()

Un fichier contenant <?php phpinfo(); envoyé sur le site affiche toute la configuration. Supprimez-le immédiatement après lecture : cette page révèle à un attaquant ce qu'il cherche. Si vous n'êtes pas à l'aise, préférez les deux méthodes précédentes.

Hébergement mutualisé (Hostinger, OVH, o2switch, etc.) : qui doit agir ?

Sur un mutualisé, PHP est géré par l'hébergeur : vous ne mettez pas à jour le moteur vous-même, vous vérifiez qu'il l'a fait. Malwarebytes le formule ainsi : mettre à jour WordPress ou ses extensions est une opération distincte de la mise à jour de PHP, et c'est l'hébergeur ou l'administrateur du serveur qui applique le correctif. Demandez-lui de confirmer que le correctif est installé, sur tous vos sites, et pas seulement planifié.

Cas documenté, Hostinger : d'après sa page d'incident, la plateforme a été jugée non vulnérable après test avec une couche de protection ajoutée le 21 octobre, puis les mises à jour de PHP ont été terminées sur l'ensemble des serveurs managés le 22 octobre. Pour les offres Web, Agency et cPanel, aucune action n'est requise de la part du client. Pour un VPS, c'est au client de gérer PHP : l'hébergeur demande de passer session.upload_progress.enabled à 0 dans php.ini puis de redémarrer PHP. Les autres hébergeurs publient leurs propres avis : consultez la page d'état du vôtre.

Serveur dédié ou VPS : que faire soi-même ?

Vous êtes l'hébergeur. Mettez à jour le paquet PHP de votre distribution (Debian, Red Hat et Alpine ont publié des paquets corrigés, d'après Wiz), redémarrez tous les processus PHP, puis contrôlez le journal du paquet pour vérifier que le correctif y figure. Conservez vos journaux avant toute modification : ils serviront en cas d'analyse (watchTowr). Si une machine ne peut pas être corrigée tout de suite, le NCSC britannique recommande en dernier recours de la mettre hors ligne.

Et si mon site est sous WordPress, Joomla ou Drupal ?

La faille est dans PHP, pas dans le CMS : un WordPress parfaitement à jour sur un PHP non corrigé reste exposé. Wiz affirme avoir obtenu une exécution de code sans authentification sur WordPress, Drupal et Joomla (via IT-Connect). Mettez quand même à jour votre CMS et vos extensions, c'est une bonne hygiène, mais ne considérez pas le sujet réglé pour autant.

Le projet PHP est clair : seule la mise à jour est une solution complète. Des réglages réduisent la surface d'attaque en attendant, et doivent être posés par la personne qui gère le serveur, puis suivis d'un redémarrage de tous les processus PHP :

• session.upload_progress.enabled = 0 : désactive le suivi de progression des téléversements, chemin d'attaque confirmé pour la seconde faille.
• Réduire post_max_size (8 Mo, ou 32 Mo si vous recevez de gros fichiers) et garder upload_max_filesize en dessous.
• Sur PHP 8.5 : fatal_error_backtraces = 0.
• Bloquer en amont (pare-feu applicatif, serveur frontal) les requêtes multipart/form-data si le site n'en a pas besoin. Cela casse aussi les formulaires avec envoi de fichier (Sansec).
• Ne pas utiliser les limites système RLIMIT_AS ou RLIMIT_DATA (php.net).

Mise en garde : la recommandation de passer memory_limit à -1 n'est valable que si la limite est confiée au conteneur ou au serveur. Sansec rappelle qu'elle expose sinon le serveur à une requête qui consomme toute la mémoire. Et watchTowr juge les seules modifications de fichiers .ini insuffisantes. Ces mesures achètent du temps, rien d'autre.

Publiée le 23 octobre, elle n'est pas corrigée par les versions du 21 octobre. Le Centre canadien, dans la mise à jour de son alerte, précise qu'elle exige une configuration inhabituelle : le suivi de progression des téléversements de session combiné à un appel à ini_set() qui change le gestionnaire de sérialisation des sessions. IT-Connect relève que la désactivation de session.upload_progress, déjà conseillée contre PHP2Shell, suffit en attendant le correctif. Hostinger indique que ses offres Web, Agency et cPanel sont protégées par l'atténuation appliquée le 21 octobre. C'est une raison de plus de désactiver ce suivi si vous n'en avez pas l'usage.

Si votre site était sur un PHP non corrigé depuis le 17 octobre (date de la première tentative signalée), regardez les indicateurs listés par watchTowr :

• Fichiers inconnus apparus dans les dossiers du site, en particulier des scripts PHP à des emplacements inhabituels.
• Tâches planifiées (cron) que vous n'avez pas créées, ou comptes d'utilisateurs ajoutés sans vous.
• Connexions sortantes inexpliquées depuis les processus PHP, ou processus PHP qui plantent ou saturent la mémoire.
• Requêtes d'envoi de fichiers anormalement volumineuses ou imbriquées dans les journaux du serveur.
• Côté visiteur : redirections vers d'autres sites, pages modifiées, alertes de votre navigateur ou de Google.

Un site qui affiche une page de maintenance n'est pas forcément compromis : Malwarebytes note que c'est souvent la précaution d'un hébergeur qui corrige. Si vous trouvez un fichier suspect, ne le supprimez pas à la hâte et ne tentez pas de « nettoyer » seul : conservez les journaux, changez les mots de passe (hébergement, base de données, administration du site) depuis un appareil sain et faites analyser le site. La page compte piraté détaille la marche à suivre pour reprendre la main.

Au-delà du cas d'école, PHP2Shell met en lumière trois faiblesses courantes en TPE et PME.

1. Personne ne sait qui gère PHP. Le site a été fait par un prestataire, hébergé par un autre, le contrat de maintenance n'existe plus. Quand une faille de ce niveau tombe, il faut pouvoir nommer le responsable de la mise à jour en une minute.
2. Des versions abandonnées par habitude. Selon CybelAngel, environ 35 % des sites WordPress tournent sur une version de PHP qui n'est plus supportée. Le jour où une faille critique sort, ces sites n'ont aucune voie de correction simple.
3. Pas de plan si la compromission a lieu. Sans sauvegarde indépendante et testée, la seule option est de reconstruire à la main. La règle 3-2-1 et le plan de reprise sont l'assurance contre ce scénario (voir sauvegarde et plan de reprise).

Un site vitrine compromis abîme votre image et peut servir de relais d'hameçonnage contre vos clients. Un site qui partage son serveur ou ses identifiants avec d'autres outils de l'entreprise pose un risque plus large : pensez à cloisonner, comme décrit dans l'article sur la segmentation du réseau et à sécuriser la messagerie avec la checklist Microsoft 365, car c'est aussi par là que les attaquants rebondissent. Pour la vue d'ensemble, voyez la checklist cybersécurité TPE/PME.

Le dernier point est celui qui évite la prochaine alerte : un suivi des versions, avec un responsable nommé. Pour les entreprises qui n'ont pas de service informatique, c'est l'objet de l'infogérance, et pour la partie réseau et sécurité de l'entreprise, de la page réseau et sécurité. Si votre site doit être refait plutôt que rafistolé, voyez nos créations de sites sur mesure.