Réponse courte : oui, si votre site tourne sur une version de PHP antérieure à 8.2.35, 8.3.36, 8.4.27 ou 8.5.12. Les failles PHP2Shell (CVE-2026-109618 et CVE-2026-109619) permettent d’exécuter du code à distance sans authentification, et le CERT-FR signale depuis le 26 octobre 2026 des tentatives d’exploitation. Mettez PHP à jour, ou exigez-le de votre hébergeur, puis vérifiez vos journaux.
Les failles PHP2Shell touchent le moteur PHP lui-même, pas un plugin. Or PHP fait tourner WordPress, Drupal, Joomla, PrestaShop et la plupart des sites vitrines et boutiques en ligne des PME. Le CERT-FR a ouvert l’alerte CERTFR-2026-ALE-014 le 21 octobre 2026 et l’a mise à jour les 26 et 27 octobre. Elle est toujours en cours. Voici ce qu’il faut savoir, et quoi faire dès cette semaine.
Que sont les failles PHP2Shell ?
Ce sont deux vulnérabilités critiques du moteur PHP, notées 9,2 sur 10 (CVSS v4.0), qui permettent à un attaquant non authentifié d’exécuter des commandes sur le serveur.
- CVE-2026-109618 : quand une requête est interrompue par un manque de mémoire, PHP peut laisser des données à moitié initialisées, puis les traiter comme valides au nettoyage.
- CVE-2026-109619 : un état propre à une requête peut survivre après la libération de sa mémoire et être réutilisé par la requête suivante sur le même processus.
Concrètement, une seule requête web forgée peut suffire à prendre la main sur le serveur. D’après Kaspersky, le chemin d’attaque confirmé passe par la fonction session.upload_progress, activée par défaut. Les chercheurs de Wiz, cités par Recorded Future, ont démontré une exécution de code à distance sans authentification contre WordPress et Drupal.
Le 23 octobre, PHP a publié une troisième faille, CVE-2026-115560. Elle exige une combinaison de réglages jugée peu probable. Sa correction est prévue dans le prochain cycle de versions.
Quelles versions de PHP sont concernées ?
Toutes les versions antérieures aux correctifs publiés le 21 octobre 2026 sont vulnérables, y compris les anciennes branches qui ne seront jamais corrigées.
| Branche PHP | Version vulnérable | Version corrigée |
|---|---|---|
| 8.5 | avant 8.5.12 | 8.5.12 ou plus |
| 8.4 | avant 8.4.27 | 8.4.27 ou plus |
| 8.3 | avant 8.3.36 | 8.3.36 ou plus |
| 8.2 | avant 8.2.35 | 8.2.35 ou plus (fin de vie le 31 décembre 2026) |
| 5.x, 7.x, 8.0, 8.1 | toutes | aucun correctif officiel : migrer |
Tous les modes d’exécution sont exposés : PHP-FPM, Apache avec mod_php, php-cgi, FrankenPHP et LiteSpeed. Selon Kaspersky, mod_php présente le risque le plus élevé. Recorded Future relève aussi que VirusTotal compte environ 5,1 millions d’adresses IP faisant tourner PHP, et que la majorité des serveurs qui affichent leur version utilisent une branche en fin de vie.
Les failles sont-elles déjà exploitées ?
Oui. Le CERT-FR a signalé le 26 octobre 2026 des tentatives d’exploitation de CVE-2026-109618 et CVE-2026-109619 visant certains déploiements de PHP.
Les attaques ont même commencé avant le correctif. Recorded Future rapporte que Patchstack a reçu de ses hébergeurs partenaires plusieurs signalements d’exploitation active dès le 21 octobre au matin, quelques heures avant la publication des nouvelles versions. Des preuves de concept circulent publiquement depuis le 22 octobre, selon le CERT-FR. Autrement dit, le temps de réaction se compte en heures, pas en semaines.
Que faire maintenant pour protéger son site ?
La seule protection complète est la mise à jour de PHP ; tout le reste ne fait que réduire la surface d’attaque, comme le rappellent le CERT-FR et l’équipe PHP.
- Identifiez votre version de PHP. Dans WordPress : Outils, puis Santé du site, onglet Infos, section Serveur. Sur un serveur : commande php -v.
- Mettez à jour vers 8.2.35, 8.3.36, 8.4.27 ou 8.5.12 minimum, en commençant par les sites exposés sur Internet. Si votre hébergeur gère le serveur, demandez-lui par écrit la confirmation du correctif.
- Attention aux paquets des distributions Linux. Avec un correctif rétroporté, le numéro de version peut ne pas changer : vérifiez le journal des modifications du paquet.
- Redémarrez PHP-FPM ou le serveur web, puis contrôlez la version réellement active.
- Si la mise à jour est impossible tout de suite, appliquez la mesure temporaire recommandée par PHP : session.upload_progress.enabled = 0 dans php.ini ou la configuration du pool, puis redémarrez chaque processus. Ajoutez si possible une règle de pare-feu applicatif (WAF).
- Quittez les branches 8.1 et antérieures. Elles ne recevront aucun correctif officiel.
- Analysez vos journaux depuis le 20 octobre 2026 : un processus web qui lance un shell, curl ou wget doit alerter.
- En cas de doute sur une compromission, isolez le serveur, conservez les journaux et changez les mots de passe et clés qui y transitent.
Pour aller plus loin, notre article sur l’importance des mises à jour de sécurité explique pourquoi ces délais comptent autant.
Mon site est chez un hébergeur mutualisé : suis-je protégé ?
Pas forcément : vous dépendez du rythme de votre hébergeur et de la version de PHP sélectionnée dans votre espace client.
Beaucoup d’hébergeurs ont corrigé vite, mais certains laissent le client choisir sa branche PHP. Si votre site est resté sur PHP 7.4 ou 8.0 « parce qu’il fonctionnait », il n’existe aucun correctif officiel pour lui. Le passage à une branche récente peut casser un vieux thème ou une extension. C’est précisément pour cela que beaucoup de sites restent bloqués sur des versions obsolètes. Testez la bascule sur une copie du site, après une sauvegarde complète.
L’avis de l’expert
Dans les grands comptes où j’ai piloté le patch management, une faille de ce niveau déclenche une procédure d’urgence : inventaire de tous les serveurs exposés, correction sous 24 à 72 heures, contrôle de conformité, puis chasse aux traces d’intrusion. Le problème des PME n’est pas la complexité du correctif. C’est l’absence d’inventaire. Personne ne sait quelle version de PHP fait tourner le site vitrine, l’intranet ou l’outil métier installé il y a cinq ans par un prestataire disparu.
Ma recommandation : tenez une liste à jour de chaque application web, de son hébergeur et de sa version de PHP. Abonnez-vous aux alertes du CERT-FR. Et considérez qu’une fin de vie annoncée, comme celle de PHP 8.2 au 31 décembre 2026, est une date limite de migration, pas une suggestion. Une gestion des correctifs structurée transforme ce type d’alerte en simple routine.
Et pour les PME et les particuliers du 92 ?
À La Garenne-Colombes, Courbevoie, Colombes ou Nanterre, nous voyons surtout des sites WordPress de commerçants, cabinets et artisans, hébergés en mutualisé et jamais revus depuis leur mise en ligne. Ce sont des cibles idéales pour des attaques automatisées comme PHP2Shell.
- PME : faites vérifier la version de PHP de chaque site et application web, et demandez une preuve de mise à jour à vos prestataires. Notre audit cybersécurité PME inclut cet inventaire.
- Particuliers avec un blog ou un site perso : connectez-vous à votre espace hébergeur et passez sur la branche PHP la plus récente proposée.
- Site déjà piraté ou comportement suspect : notre réponse à incident cyber intervient 24 h/24 et 7 j/7 dans les Hauts-de-Seine, et à distance partout en France.
Questions fréquentes
Qu’est-ce que PHP2Shell ?
PHP2Shell est le surnom donné aux failles CVE-2026-109618 et CVE-2026-109619 du moteur PHP. Elles permettent à un attaquant non authentifié d’exécuter du code sur un serveur web. Elles sont corrigées depuis le 21 octobre 2026.
Comment savoir si mon site WordPress est vulnérable ?
Ouvrez Outils, puis Santé du site, onglet Infos, section Serveur, pour voir la version de PHP. Si elle est inférieure à 8.2.35, 8.3.36, 8.4.27 ou 8.5.12, votre site est exposé. Les branches 8.1 et antérieures le restent en permanence.
Mettre à jour WordPress suffit-il ?
Non. La faille se trouve dans PHP, le langage qui exécute WordPress, et non dans WordPress lui-même. C’est le serveur qui doit être mis à jour, par vous ou par votre hébergeur.
Désactiver session.upload_progress protège-t-il complètement ?
Non. Cette mesure réduit l’exposition en attendant la mise à jour, mais PHP et le CERT-FR précisent que seule l’installation des versions corrigées protège réellement. Il faut aussi redémarrer chaque processus PHP après le changement.
Que faire si je pense que mon site a été piraté ?
Isolez le site ou mettez-le en maintenance, conservez les journaux du serveur et changez tous les mots de passe associés. Faites ensuite analyser le serveur par un professionnel avant de le remettre en ligne.
En résumé
- Les failles PHP2Shell permettent de prendre le contrôle d’un serveur web à distance, et le CERT-FR constate des tentatives d’exploitation depuis le 26 octobre 2026.
- La seule protection complète est de passer à PHP 8.2.35, 8.3.36, 8.4.27 ou 8.5.12 minimum, et d’abandonner les branches 8.1 et antérieures.
- Vérifiez vos journaux depuis le 20 octobre et tenez un inventaire de vos applications web et de leurs versions de PHP.
Besoin d’un coup de main ? SOSPC82 vérifie et met à jour vos sites et serveurs, puis surveille vos correctifs dans la durée avec notre infogérance PME, à partir de 19,99 € HT par poste et par mois. Appelez le 07 69 36 92 60, devis gratuit sous 24 h.
Article rédigé par Kevin Aquino, Technical Lead patch management et fondateur de SOSPC82
Sources :
- CERT-FR, alerte CERTFR-2026-ALE-014 « Multiples vulnérabilités dans PHP » (mise à jour du 27 octobre 2026)
- CERT-FR, message du 26 octobre 2026 sur les tentatives d’exploitation
- PHP.net, archives des annonces 2026 (avis du 20, 21 et 23 octobre 2026)
- Kaspersky, « PHP2Shell » : CVE-2026-109618 et CVE-2026-109619
- Recorded Future, PHP2Shell Exploitation: Two Critical PHP Flaws Explained