PHP2Shell et une 2e faille PHP : ce qu'une TPE doit vérifier

Code source PHP affiché sur un écran d'ordinateur

Le 21 octobre 2026, la PHP Foundation a publié un correctif en urgence pour deux failles critiques surnommées PHP2Shell (CVE-2026-109618 et CVE-2026-109619), avec un score de gravité maximal (CVSS 9,2 sur 10). Le lendemain, la CISA (l'agence américaine de cybersécurité) a publié une alerte officielle demandant un correctif immédiat : des tentatives d'exploitation ont été observées avant même la sortie du patch, et un exploit public a été diffusé fin octobre.

Si vous dirigez une TPE et que votre site est un WordPress, un PrestaShop ou n'importe quel CMS construit sur PHP — ce qui concerne une très large majorité des sites de petites entreprises — cette faille vous concerne directement, même si vous ne faites jamais de ligne de code. Deux jours plus tard, le 23 octobre, une seconde faille PHP distincte (CVE-2026-115560) a été révélée : beaucoup moins grave, mais à connaître pour ne pas la confondre avec PHP2Shell. Cet article explique ce qu'il faut comprendre sur les deux, qui doit agir, et comment vérifier concrètement.

PHP2Shell, en clair : qu'est-ce que c'est ?

PHP est le langage de programmation sur lequel tourne la très grande majorité des sites et boutiques en ligne de petites entreprises : WordPress, PrestaShop, et de nombreux autres CMS ou outils de gestion sont écrits en PHP. Quand un visiteur charge une page de votre site, c'est le moteur PHP installé sur votre serveur qui exécute le code et génère la page affichée.

PHP2Shell désigne deux failles découvertes dans ce moteur lui-même, pas dans un plugin ou un thème particulier :

CVE-2026-109618 : une corruption de mémoire (dépassement de capacité) qui peut être détournée pour exécuter du code à distance.
CVE-2026-109619 : un problème d'état interne du serveur qui subsiste après l'arrêt anormal d'une requête, lui aussi exploitable pour exécuter du code à distance.

Dans les deux cas, le résultat pour un attaquant est le même : une exécution de code à distance sans authentification. Autrement dit, un attaquant n'a besoin ni d'un mot de passe, ni d'un compte administrateur sur votre site : il lui suffit d'envoyer une requête spécialement construite à votre serveur pour en prendre le contrôle. La faille a été confirmée exploitable sur la configuration la plus répandue sur l'hébergement mutualisé (Apache avec mod_php) en conditions de production normales — pas seulement en laboratoire.

Pourquoi c'est particulièrement grave, et pas juste « une faille de plus »

Des failles critiques dans des CMS, on en voit régulièrement : GLSM en a déjà documenté plusieurs, par exemple la faille WP2Shell du cœur de WordPress ou la faille du plugin « The Plus Addons for Elementor ». Ce qui distingue PHP2Shell, c'est son niveau dans la pile technique : elle touche le moteur PHP lui-même, c'est-à-dire la fondation sur laquelle WordPress, PrestaShop et des milliers d'autres outils sont construits. Elle ne dépend d'aucune extension particulière : toute installation PHP non corrigée est concernée, quel que soit le CMS utilisé par-dessus.

Et surtout : l'exploitation n'est pas théorique. Plusieurs sociétés de cybersécurité ont signalé des tentatives d'exploitation avant même la publication du correctif officiel le 21 octobre 2026, et un exploit fonctionnel a été rendu public fin octobre par la société VulnCheck, capable de contourner une protection de sécurité standard des systèmes (l'ASLR) sur les serveurs x86-64 les plus courants. C'est pour cette raison que la CISA a jugé nécessaire de publier une alerte officielle le jour même de la divulgation, demandant une correction immédiate plutôt qu'une mise à jour « au prochain cycle de maintenance » (alerte officielle CISA).

Concrètement, pour une TPE dont le site tourne sur une version non corrigée, le risque n'est pas une simple dégradation visuelle du site : un attaquant qui exploite la faille peut déposer ses propres fichiers sur votre serveur, lire ou modifier votre base de données (coordonnées clients, commandes, mots de passe), rediriger vos visiteurs vers un site frauduleux, ou utiliser votre serveur comme relais pour attaquer d'autres cibles — souvent sans que rien de visible n'alerte immédiatement le gérant du site.

Qui est réellement concerné ? Hébergement mutualisé vs serveur dédié

C'est le point le plus utile à comprendre pour ne pas paniquer inutilement : toutes les TPE ne sont pas exposées au même degré, selon la façon dont leur site est hébergé.

Hébergement mutualisé ou géré (le cas de la grande majorité des sites de TPE : OVH, o2switch, Hostinger, LWS et équivalents, ou un site WordPress/PrestaShop hébergé via une offre « clé en main ») : dans ce cas de figure le plus fréquent, c'est l'hébergeur qui gère la version de PHP installée sur ses serveurs, et qui applique en principe les correctifs de sécurité critiques de façon automatique et rapide, sans action du client. C'est la situation la plus rassurante, mais elle ne dispense pas de vérifier — voir plus bas.
Serveur dédié ou VPS en autogestion : si votre site tourne sur un serveur dont vous (ou votre prestataire) gérez vous-même la configuration système, personne n'applique le correctif à votre place. La mise à jour de PHP vers une version corrigée (8.5.12, 8.4.27, 8.3.36 ou 8.2.35, selon la branche utilisée) doit être effectuée manuellement, et tant qu'elle ne l'est pas, le serveur reste exposé à une prise de contrôle totale.
Site confié à un prestataire d'infogérance ou de maintenance : c'est à ce prestataire d'avoir déjà vérifié et appliqué le correctif. C'est précisément le genre d'intervention qu'un contrat de maintenance de site internet couvre normalement : une faille critique du moteur sous-jacent du site fait partie des mises à jour de sécurité que le prestataire doit appliquer sans attendre, sans facturation additionnelle si elle est incluse dans le forfait.

Dans tous les cas, l'important n'est pas de deviner votre situation : c'est de la vérifier explicitement, ce qui prend en général moins de dix minutes par un échange avec la bonne personne.

Comment vérifier concrètement, sans compétence technique

Voici la démarche la plus simple pour une TPE, sans avoir besoin de toucher au code ou au serveur soi-même :

Identifier qui gère l'hébergement. Si vous ne savez pas qui gère votre serveur, la facture d'hébergement (OVH, Ionos, un prestataire local…) ou votre contrat de création/maintenance de site donne la réponse.
Contacter directement cet hébergeur ou ce prestataire et demander explicitement : « Mon site est-il concerné par la faille PHP2Shell (CVE-2026-109618 / CVE-2026-109619) publiée le 21 octobre 2026 ? Quelle version de PHP est active sur mon hébergement, et a-t-elle été mise à jour ? » Une version corrigée doit être au minimum PHP 8.2.35, 8.3.36, 8.4.27 ou 8.5.12 (ou un backport de sécurité équivalent pour les branches plus anciennes).
Ne pas se contenter d'une réponse vague. « C'est bon, on gère ça » n'est pas une confirmation suffisante pour une faille de ce niveau de gravité : demander la version PHP exacte et la date d'application du correctif est une question légitime, pas de la méfiance excessive.
Ne pas attendre le prochain cycle de maintenance habituel. Une faille déjà exploitée activement, avec un exploit public disponible, justifie une vérification immédiate, pas une mise à jour « à l'occasion ».

Si votre site vous semble déjà anormal (redirections inattendues, fichiers ou pages que vous n'avez pas créés, ralentissements soudains), traitez cela comme un signal d'alerte potentiel plutôt qu'un simple bug : la marche à suivre est détaillée dans notre article « Site non sécurisé : que faire ? ».

Une deuxième faille PHP (CVE-2026-115560) : faut-il s'inquiéter aussi ?

Le 23 octobre 2026, deux jours après la publication des correctifs PHP2Shell, l'équipe officielle de PHP a révélé une faille distincte, référencée CVE-2026-115560 (bulletin officiel sur php.net, référence GHSA-6wmf-4rv5-p3rp). Elle n'est pas corrigée par les mises à jour du 21 octobre (8.5.12, 8.4.27, 8.3.36, 8.2.35) : c'est un problème à part, autour de la fonctionnalité « Session Upload Progress ».

Il est important de garder cette seconde annonce à sa juste mesure, sans l'amalgamer avec PHP2Shell : l'équipe PHP elle-même indique qu'une exécution de code à distance via cette faille est jugée peu probable, car elle suppose la réunion de trois conditions inhabituelles en même temps :

le réglage session.serialize_handler positionné sur php_binary ou php_serialize (pas la valeur par défaut) ;
le code de l'application qui repasse ce réglage sur php via ini_set() juste avant session_start() ;
la fonctionnalité « Session Upload Progress » toujours active (elle l'est par défaut sur une installation PHP standard).

Autre différence notable avec PHP2Shell : aucun score de gravité (CVSS) n'a été communiqué, aucune liste précise de versions affectées n'a été publiée, et PHP n'a annoncé aucune version corrigée dans l'urgence. Ce dossier est traité dans le cycle de maintenance normal du projet, pas comme une alerte critique à corriger immédiatement — un contraste volontaire avec le traitement de PHP2Shell, qui avait justifié une alerte officielle de la CISA.

La mitigation recommandée est la même que l'une de celles déjà conseillées contre PHP2Shell (en particulier CVE-2026-109619) : désactiver le réglage session.upload_progress.enabled en le mettant à 0, directement dans le fichier php.ini ou dans la configuration du pool PHP-FPM ou du serveur web, puis redémarrer les processus PHP. Ce réglage ne peut pas être neutralisé via ini_set() ni via un fichier .user.ini : pour cette directive précise, seule la configuration serveur fonctionne.

Si votre hébergeur ou votre prestataire a déjà désactivé ce réglage dans le cadre du traitement de PHP2Shell, il n'y a rien de plus à faire pour cette seconde faille. C'est un point rassurant à vérifier simplement dans le même échange que celui évoqué plus haut. PHP recommande d'ailleurs de garder ce réglage désactivé en permanence si la fonctionnalité d'upload avec barre de progression n'est pas utilisée sur le site, car elle est de plus en plus ciblée par des attaquants alors qu'elle reste peu testée. Plus de détails techniques sur it-connect.fr.

Ce que fait GLSM pour ses clients en maintenance

Pour les sites suivis dans le cadre d'un contrat de maintenance GLSM, la vérification et, si nécessaire, la mise à jour vers une version de PHP corrigée font partie des interventions de sécurité prioritaires couvertes par le forfait, sans surcoût. C'est exactement le type d'alerte pour lequel un contrat de maintenance a de la valeur : quelqu'un qui surveille activement ce genre d'annonce de sécurité à votre place, plutôt que d'en découvrir l'existence le jour où le site est compromis.

Questions fréquentes

Mon site WordPress est-il automatiquement protégé ?

Non, pas automatiquement par WordPress lui-même : PHP2Shell touche le moteur PHP qui fait fonctionner WordPress, pas WordPress en tant que tel. La protection dépend de la version de PHP installée sur le serveur d'hébergement, pas d'une mise à jour de plugin ou de thème.

Comment savoir si mon hébergeur a déjà appliqué le correctif ?

Le plus fiable est de poser la question directement à votre hébergeur ou à votre prestataire, en citant les CVE (CVE-2026-109618 et CVE-2026-109619) et en demandant la version de PHP active sur votre compte. Les grands hébergeurs mutualisés communiquent en général rapidement sur ce type d'incident critique dans leur centre d'aide ou par e-mail à leurs clients.

Si mon site est touché, comment je le saurais ?

Pas forcément de façon visible : une prise de contrôle via cette faille peut rester discrète pendant un temps (dépôt de fichiers cachés, accès en arrière-plan). Les signes à surveiller : redirections inattendues des visiteurs, pages ou comptes administrateurs inconnus, ralentissement soudain, alertes de votre hébergeur ou de Google Search Console sur un contenu suspect.

Conclusion

PHP2Shell n'est pas une faille à classer dans la pile des alertes génériques qu'on laisse passer : elle touche le socle technique de la quasi-totalité des sites de TPE, elle est déjà exploitée activement, et un exploit public circule. La bonne nouvelle, c'est que la vérification est simple et rapide pour qui sait à qui poser la question : votre hébergeur ou votre prestataire de maintenance, avec la version de PHP active et la date du correctif comme seules informations à obtenir.

Pour vérifier la sécurité de votre site ou mettre en place un suivi sérieux de ce type d'alerte, contactez-nous : on vous répond simplement, sans jargon.

À lire aussi :