Faille PHP2Shell : votre site est-il exposé et que faire maintenant ?

Deux failles critiques viennent d’être révélées au cœur de PHP, le langage qui fait tourner la grande majorité des sites vitrines et des boutiques en ligne. Baptisées PHP2Shell par les chercheurs (CVE-2026-109618 et CVE-2026-109619), elles permettent à un attaquant d’exécuter du code à distance sur le serveur qui héberge votre site. L’équipe de sécurité de PHP leur attribue une note de gravité de 9,2 sur 10.

Le correctif est programmé pour le 21 octobre 2026 à 16 h (heure de Paris), mais uniquement pour les versions encore maintenues : PHP 8.2, 8.3, 8.4 et 8.5. Si votre site tourne en PHP 8.1 ou sur une version plus ancienne, aucune mise à jour ne viendra le protéger. La seule vraie solution, c’est de migrer.

PHP2Shell en deux mots

PHP est le moteur qui travaille côté serveur : c’est lui qui fabrique vos pages, traite vos formulaires et dialogue avec votre base de données. La plupart des CMS du marché reposent dessus. Quand une faille touche une extension, on peut la désactiver en attendant mieux. Ici, c’est le socle lui-même qui est en cause.

Une faille d’exécution de code à distance, c’est le scénario le plus grave pour un site web. Un attaquant envoie une requête bien construite et fait exécuter sur votre serveur les instructions de son choix, sans avoir besoin de vos identifiants. Concrètement, il peut :

• installer une porte dérobée pour revenir quand il le souhaite ;
• copier les données de vos clients, de vos commandes ou de vos formulaires ;
• injecter du code malveillant ou rediriger vos visiteurs vers des sites frauduleux ;
• se servir de votre serveur pour envoyer du spam ou attaquer d’autres sites.

Le fonctionnement technique des deux failles n’a pas été publié, et c’est volontaire : le but est de laisser le temps aux hébergeurs d’installer le correctif. Des chercheurs évoquent un lien avec la gestion des sessions et des envois de fichiers, sans confirmation officielle à ce jour.

Pourquoi il faut agir maintenant

L’existence des failles a fuité le 20 octobre, avant même l’annonce officielle. L’équipe de PHP a alors publié un préavis et avancé la sortie du correctif. Depuis, des codes d’attaque présentés comme fonctionnels circulent sur Internet. Leur fiabilité n’est pas vérifiée, et certains pourraient eux-mêmes contenir des logiciels malveillants, mais leur seule existence montre que des attaquants s’y intéressent déjà.

Au 21 octobre, aucune exploitation massive n’était confirmée. Le précédent invite pourtant à ne pas attendre : en 2024, une autre faille critique de PHP (CVE-2024-4577) a fait l’objet de tentatives d’attaque dans les 24 heures qui ont suivi sa publication, comme le rappelle The Hacker News.

Le nombre de sites exposés est considérable. Selon une estimation relayée par la même source, environ 884 000 serveurs accessibles sur Internet annoncent une version de PHP égale ou antérieure à 8.1, donc sans correctif possible. Ce chiffre repose sur les informations affichées par les serveurs : il donne un ordre de grandeur, pas un décompte exact.

Quelles versions recevront un correctif

Toutes les versions de PHP ne sont pas logées à la même enseigne. Les versions en fin de vie ne reçoivent plus aucune mise à jour de sécurité, même pour une faille de cette gravité.

Version de PHP	Statut de maintenance	Correctif PHP2Shell	Ce qu’il faut faire
5.x et 7.x	Fin de vie depuis plusieurs années	Aucun	Migrer en priorité absolue
8.0	Fin de vie depuis novembre 2023	Aucun	Migrer vers 8.3 ou 8.4
8.1	Fin de vie depuis le 31 décembre 2025	Aucun	Migrer vers 8.3 ou 8.4
8.2	Sécurité assurée jusqu’au 31 décembre 2026	Oui (8.2.35 attendue)	Mettre à jour, puis prévoir la migration
8.3	Sécurité assurée jusqu’au 31 décembre 2027	Oui (8.3.36 attendue)	Mettre à jour
8.4	Sécurité assurée jusqu’au 31 décembre 2028	Oui (8.4.27 attendue)	Mettre à jour
8.5	Sécurité assurée jusqu’au 31 décembre 2029	Oui (8.5.12 attendue)	Mettre à jour

Un point d’attention sur PHP 8.2 : il sera bien corrigé, mais sa maintenance s’arrête dans quelques semaines. Migrer un vieux site vers 8.2 aujourd’hui reviendrait à se préparer une nouvelle migration début 2027. Pour tout projet de migration, visez directement 8.3 ou 8.4.

Comment savoir si votre site est concerné

Trouver la version de PHP de votre site

La version de PHP s’affiche en général dans le panneau de gestion de votre hébergement, rubrique PHP ou paramètres du domaine. La plupart des CMS l’indiquent aussi dans leur outil de diagnostic ou d’état de santé, accessible depuis l’administration. Si vous ne trouvez pas, votre hébergeur ou votre prestataire web peut vous répondre en quelques minutes.

Vérifiez bien la version utilisée par le site lui-même. Un serveur peut avoir plusieurs versions de PHP installées, et ce n’est pas forcément la plus récente qui sert vos pages.

Savoir qui doit installer le correctif

C’est la question que beaucoup de dirigeants se posent, et la réponse dépend de votre type d’hébergement :

Type d’hébergement	Qui installe le correctif	Votre rôle
Mutualisé ou infogéré	L’hébergeur	Lui demander la date de mise à jour, puis vérifier la version
Serveur dédié ou virtuel	Vous ou votre prestataire	Planifier la mise à jour et le redémarrage des services
Conteneurs	Vous ou votre prestataire	Reconstruire les images avec la nouvelle version et redéployer

Dans tous les cas, une mise à jour n’est effective qu’une fois les services PHP redémarrés. Un contrôle de la version réellement utilisée par le site, après l’intervention, évite les mauvaises surprises.

Que faire selon votre situation

Votre site tourne en PHP 8.2 ou plus récent

Vous êtes dans le cas le plus simple. Assurez-vous que votre hébergeur ou votre prestataire installe le correctif le plus vite possible après sa sortie, idéalement dans la journée. Demandez-lui une date précise plutôt qu’un « dès que possible », puis vérifiez la version affichée une fois l’intervention faite.

Si vous êtes en 8.2, profitez-en pour programmer dès maintenant la migration vers 8.3 ou 8.4, avant la fin de sa maintenance.

Votre site tourne en PHP 8.1 ou plus ancien

Ici, attendre ne sert à rien : aucun correctif ne viendra. Il faut migrer vers une version maintenue. Une migration se prépare : copie du site sur un environnement de test, mise à jour du CMS, du thème et des extensions, correction du code incompatible, puis bascule. C’est aussi l’occasion de faire le ménage et de renforcer la configuration, comme nous l’expliquons dans notre article sur la sécurisation des CMS e-commerce.

Plus le site est ancien, plus la migration risque de révéler des extensions abandonnées ou du code à reprendre. Mieux vaut lancer le diagnostic tout de suite, même si la bascule demande quelques jours.

En attendant la migration

Si la migration ne peut pas se faire immédiatement, quelques mesures réduisent l’exposition :

• couper l’accès public aux sites de test, de préproduction ou qui ne servent plus ;
• restreindre l’accès aux espaces d’administration (adresses IP autorisées, réseau privé) ;
• placer le site derrière un pare-feu applicatif capable de filtrer les requêtes suspectes ;
• désactiver l’option de suivi de progression des envois de fichiers (session.upload_progress.enabled = Off), piste évoquée par des chercheurs mais non confirmée officiellement ;
• surveiller les fichiers modifiés récemment et les journaux du serveur.

Ces mesures limitent le risque, elles ne le suppriment pas. Elles achètent du temps pour migrer, rien de plus.

Et si votre site a déjà été touché

Certains signes doivent alerter : des fichiers inconnus à la racine du site, des redirections étranges, un compte administrateur que personne n’a créé, des tâches planifiées inhabituelles ou un serveur qui ralentit sans raison. Une intrusion en cache souvent une autre, comme le montre notre retour d’expérience sur un site piraté par plusieurs intrus.

En cas de doute, isolez le site, conservez les journaux du serveur et ne vous contentez pas de restaurer une sauvegarde : sans correction de la faille, l’attaquant reviendra par le même chemin. Changez ensuite tous les mots de passe (administration, base de données, accès au serveur) et faites analyser le site avant de le remettre en ligne.

Faire de la mise à jour une habitude

PHP2Shell rappelle une réalité que beaucoup de dirigeants découvrent dans l’urgence : un site web n’est jamais terminé. Le CMS, les extensions, mais aussi le langage et le serveur qui les font tourner vieillissent et doivent être suivis. Un site resté en PHP 7.4 ou 8.0 depuis sa mise en ligne n’a rien fait de mal, il a simplement été oublié. Et c’est exactement ce type de site que les attaquants recherchent.

La bonne réponse n’est pas de courir après chaque alerte, mais de confier ce suivi à quelqu’un dont c’est le métier. Chez Zetruc, notre maintenance de site internet inclut le suivi des versions de PHP et des mises à jour de sécurité, et notre hébergement de sites et de boutiques en ligne s’accompagne du même suivi. Vous ne savez pas sur quelle version tourne votre site, ou vous voulez préparer une migration ? Parlons de votre site, on vous répond rapidement.