Faille PHP2Shell : faut-il mettre à jour PHP sur le site de votre PME ?

Deux failles critiques de PHP, baptisées PHP2Shell, ont été corrigées le 21 octobre 2026. Comment savoir si votre site est concerné et quoi demander à votre hébergeur.

Si votre site ou votre application tourne en PHP, oui, il faut mettre à jour PHP maintenant. Le 21 octobre 2026, l'équipe du langage a publié les versions 8.5.12, 8.4.27, 8.3.36 et 8.2.35 pour corriger deux failles critiques, regroupées sous le nom PHP2Shell. Elles permettent à un attaquant d'exécuter du code sur le serveur sans avoir besoin de se connecter. La bonne nouvelle, c'est que le correctif existe déjà et qu'il s'applique en général sans toucher au code de votre site.

WordPress, Drupal, Joomla, PrestaShop, Symfony, Laravel ou Sulu reposent tous sur PHP. Beaucoup de PME utilisent donc PHP sans le savoir, parfois aussi dans un outil interne ou une interface d'administration. Voici comment savoir si vous êtes concerné et quoi demander à votre agence ou à votre hébergeur.

Que s'est-il passé avec la faille PHP2Shell ?

Le 20 octobre, l'équipe de PHP a annoncé une mise à jour de sécurité urgente pour le lendemain. Le 21 octobre, elle a publié son avis de sécurité officiel sur php.net. Il décrit deux vulnérabilités notées 9,2 sur 10 (CVSS 4.0), le niveau critique.

• CVE-2026-109618 : quand PHP manque de mémoire au mauvais moment, par exemple pendant l'envoi d'un fichier par formulaire, le nettoyage de la requête peut manipuler des données mal initialisées. Un attaquant peut en tirer parti pour exécuter son propre code.
• CVE-2026-109619 : certaines informations internes d'une requête peuvent survivre après une erreur fatale. La requête suivante traitée par le même processus risque alors de les réutiliser, ce qui ouvre là aussi la porte à l'exécution de code.

Selon l'équipe de PHP, toutes les installations qui répondent à des requêtes web sont exposées : PHP-FPM, Apache avec mod_php, php-cgi, FrankenPHP et LiteSpeed. Le risque le plus élevé concerne mod_php, pour lequel une démonstration montre qu'une seule requête anonyme suffit à déclencher l'attaque, avant même que le code du site ne s'exécute.

Comment savoir si mon site est concerné ?

La question à se poser est simple : votre site, votre boutique ou votre outil métier fonctionne-t-il avec PHP ? Si vous utilisez un CMS comme WordPress, la réponse est presque toujours oui. Pour un site développé sur mesure, la personne qui l'a construit vous le dira en une minute.

Le Centre national pour la cybersécurité suisse insiste sur un point dans son alerte du 21 octobre : il ne faut pas regarder uniquement le site public. PHP peut aussi tourner derrière une interface d'administration, une application interne, une plateforme d'hébergement ou un équipement réseau, sans que l'entreprise le sache.

Comment vérifier la version de PHP de mon site ?

Plusieurs chemins existent, selon votre installation :

• Dans WordPress, le menu Outils puis Santé du site, onglet Informations, indique la version de PHP du serveur.
• Chez la plupart des hébergeurs mutualisés, l'espace client affiche la version de PHP de chaque hébergement et permet souvent d'en changer.
• Sur un serveur que vous gérez, la commande php -v donne la version installée en ligne de commande. Vérifiez aussi celle qui sert réellement les pages, qui peut être différente.

Une version égale ou supérieure à 8.5.12, 8.4.27, 8.3.36 ou 8.2.35 sur sa branche est corrigée. Attention à un piège : les distributions Linux appliquent souvent le correctif sur leur propre numéro de paquet. Un serveur peut donc afficher un numéro plus ancien tout en étant protégé. Dans ce cas, c'est le bulletin de sécurité de la distribution qui fait foi.

Que faire si mon site tourne encore en PHP 8.1 ou en PHP 7 ?

Le projet PHP ne publie plus de mises à jour pour PHP 8.1 et les versions antérieures. Certaines distributions et des prestataires de support étendu proposent malgré tout un correctif, et l'équipe de PHP a fourni des correctifs minimaux pour PHP 7.4, 8.0 et 8.1 à destination de ceux qui compilent eux-mêmes. C'est une solution de dépannage. La vraie réponse consiste à passer sur une version maintenue.

Ce passage demande parfois d'adapter le code, surtout pour un site ancien ou un module développé il y a plusieurs années. C'est souvent le bon moment pour faire le point sur l'outil, comme on l'expliquait à propos du coût d'un logiciel sur mesure pour une PME. Notez aussi que PHP 8.2 ne recevra plus de correctifs de sécurité après le 31 décembre 2026.

Quelles questions poser à mon agence ou à mon hébergeur ?

Vous n'avez pas besoin de faire la mise à jour vous-même. En revanche, vous pouvez demander une confirmation écrite. Voici les questions qu'on poserait à votre place :

• Quelle version de PHP sert aujourd'hui mon site, et est-elle corrigée contre CVE-2026-109618 et CVE-2026-109619 ?
• Les processus PHP ont-ils été redémarrés après la mise à jour ? Sans redémarrage, l'ancienne version peut continuer à répondre.
• Mes autres outils en PHP (back-office, extranet, application interne) ont-ils été vérifiés eux aussi ?
• Les journaux du serveur montrent-ils des requêtes inhabituelles, des plantages ou des fichiers modifiés ces derniers jours ?

Ce dernier point compte. Le centre suisse le rappelle : une mise à jour ferme la faille, mais elle n'efface pas une intrusion qui aurait déjà eu lieu. Si votre site est hébergé sur un serveur dédié ou un VPS, quelqu'un doit aussi reconstruire les conteneurs le cas échéant. C'est l'un des avantages d'un hébergement et d'un déploiement automatisés, où une nouvelle image se redéploie en quelques minutes.

Et si la mise à jour ne peut pas être faite tout de suite ?

L'équipe de PHP décrit des réglages temporaires, comme désactiver la barre de progression des envois de fichiers (session.upload_progress.enabled) ou limiter la taille des requêtes. Elle précise qu'ils réduisent certains chemins d'attaque sans rendre l'installation sûre. Ils peuvent aussi casser des formulaires ou des envois de documents. Pour un site d'entreprise, on les réserve à quelques heures de transition, le temps d'appliquer le vrai correctif.

Si un outil sensible ne peut vraiment pas être mis à jour, le centre suisse conseille de restreindre son accès aux seules personnes qui en ont besoin, voire de le couper temporairement d'internet.

Pourquoi une petite entreprise est-elle aussi visée ?

Une attaque comme celle-ci ne vise pas une entreprise en particulier. Des robots parcourent internet à la recherche de serveurs qui n'ont pas encore été mis à jour, quelle que soit la taille de la société derrière. On retrouve la même logique que dans l'attaque sur les frigos connectés des supermarchés. C'est le maillon le moins surveillé qui cède en premier.

Pour vos propres outils, la sécurité se joue autant dans le suivi que dans le développement. Quand on conçoit un logiciel sur mesure, on prévoit dès le départ qui surveille les avis de sécurité et en combien de temps les correctifs partent en production. Sur le même thème, notre article sur les passkeys et la fuite du mot de passe « 123456 » montre comment protéger les accès à ces outils.

Vous ne savez pas quelle version de PHP fait tourner votre site, ou vous voulez une vérification rapide de vos outils ? On est à Rumilly, près d'Annecy, et on regarde ça avec vous, sans jargon.