Une erreur de mémoire
Quand PHP manque de mémoire pendant le traitement d'une requête, il peut laisser des données à moitié préparées, puis les utiliser comme si elles étaient valides (CVE-2026-109618).
Failles PHP2Shell d'octobre 2026 : ce qu'il faut savoir pour votre site
Le 21 octobre 2026, l'équipe de PHP a publié en urgence le correctif de deux failles critiques, surnommées PHP2Shell. PHP fait tourner WordPress, WooCommerce, Magento et une grande partie des sites web. Les faits viennent des bulletins de l'équipe de PHP, du CERT-FR et de Sansec.
Ce qui s'est passé
- 20 octobre : l'équipe de PHP annonce pour le lendemain une mise à jour de sécurité critique, sans détail technique.
- 21 octobre au matin : Cloudflare signale de premières attaques, avant même la sortie du correctif (d'après Sansec, société spécialisée en sécurité).
- 21 octobre, 16 h (heure de Paris) : publication des versions corrigées PHP 8.5.12, 8.4.27, 8.3.36 et 8.2.35. Le même jour, le CERT-FR, l'agence française chargée des alertes de sécurité, publie une alerte.
- 22 octobre : le CERT-FR indique avoir connaissance de preuves de concept, c'est-à-dire du code qui montre comment exploiter les failles sur certaines installations de PHP.
- 23 octobre : l'équipe de PHP conseille de garder désactivé le suivi des envois de fichiers jusqu'à sa prochaine mise à jour, à cause d'une troisième faille (CVE-2026-115560), qui suppose une configuration peu probable.
Le CERT-FR signale aussi des tentatives d'exploitation des deux failles. D'après Sansec, les preuves de concept publiées ne fonctionnent pas sur une installation de PHP par défaut.
Les versions 8.1 et plus anciennes ne sont plus suivies par l'équipe de PHP et n'ont pas de nouvelle version corrigée. L'équipe a seulement publié, pour les versions 7.4, 8.0 et 8.1, un correctif que les hébergeurs et les éditeurs de systèmes peuvent intégrer à leur propre PHP. PHP 8.2 arrive lui-même en fin de support le 31 décembre 2026.
Deux failles notées 9,2 sur 10
Des restes d'une requête précédente
Une information liée à une requête (une visite du site) peut survivre à la libération de sa mémoire. La requête suivante, traitée par le même programme PHP, peut alors s'en servir (CVE-2026-109619).
Sans mot de passe
Dans les deux cas, un attaquant peut, dans certaines conditions, exécuter du code sur le serveur depuis Internet, sans compte ni mot de passe. Il agit alors avec les droits du site : lire ses fichiers et sa base de données, les modifier, ou s'en servir pour aller plus loin.
Qui est vraiment exposé
Le risque dépend de la façon dont PHP est relié au logiciel qui reçoit les visiteurs sur le serveur. C'est un réglage de l'hébergeur, que vous ne voyez pas. D'après les bulletins de l'équipe de PHP :
- Avec mod_php (PHP intégré au serveur web Apache), l'attaque est confirmée pour les deux failles, avant même que le code du site s'exécute.
- Avec PHP-FPM (PHP qui tourne à part du serveur web), l'attaque a été démontrée pour la seconde faille, en passant par le suivi des envois de fichiers, actif par défaut. Pour la première, le risque vient de l'analyse du code, sans attaque complète démontrée.
- Avec les serveurs LiteSpeed et FrankenPHP, le risque est jugé possible, sans attaque démontrée.
Dans tous les cas, d'après l'équipe de PHP, la mise à jour est la seule protection complète. Les réglages proposés en attendant, comme la désactivation du suivi des envois de fichiers (session.upload_progress), réduisent le risque sans le supprimer.
Mettre à jour WordPress ne met pas à jour PHP
WordPress, ses extensions et son thème sont des fichiers de votre site. PHP, lui, est installé sur le serveur : c'est votre hébergeur qui le met à jour, ou votre prestataire si vous avez un serveur dédié. Un site WordPress à jour pouvait donc rester exposé.
Chez certains hébergeurs, la version corrigée garde aussi le même numéro. Ils appliquent le correctif à la version de PHP qu'ils préparent eux-mêmes, sans passer à la version officielle. Voir "PHP 8.2" dans l'administration de votre site ne dit donc pas si le correctif est installé.
Comment je l'ai traité pour les sites que je suis
J'ai été prévenu dans la nuit du 20 au 21 octobre, une quinzaine d'heures avant la publication du correctif. Les sites que je maintiens sont répartis chez plusieurs hébergeurs, et c'est à eux d'installer le correctif sur leurs serveurs.
Dans la nuit, j'ai demandé à chacun quand il installerait le correctif, s'il couvrait les anciennes versions de PHP et si les réglages provisoires étaient possibles en attendant.
Comme le numéro de version ne change pas toujours, j'ai ensuite vérifié moi-même sur chaque serveur la date à laquelle PHP avait été préparé, sans rien y modifier. J'ai prévenu chaque client une fois la mise à jour vérifiée sur son serveur, avec ce message : "Votre site est protégé : la mise à jour de PHP est installée sur son serveur, je l'ai vérifié moi-même. Vous n'avez rien à faire."
Ce que vous pouvez faire
- Demandez à votre hébergeur, ou à la personne qui s'occupe de votre site, si le correctif de PHP du 21 octobre 2026 est installé sur le serveur de votre site, pas seulement disponible.
- Demandez quelle version de PHP utilise votre site. En 8.1 ou plus ancienne, il n'y a pas de nouvelle version corrigée : vérifiez que l'hébergeur a intégré le correctif, et prévoyez de passer à une version suivie.
- Si votre site est en PHP 8.2, prévoyez aussi le passage à une version plus récente avant la fin de son support, le 31 décembre 2026.
- Si vous constatez quelque chose d'anormal sur votre site ces dernières semaines, faites-le examiner : un correctif installé après coup n'efface pas une intrusion qui aurait eu lieu avant.
Questions fréquentes
Mon site WordPress est-il concerné ?
Tous les sites qui fonctionnent avec PHP l'étaient tant que le correctif n'était pas installé sur leur serveur, quelle que soit la version de WordPress. Le plus simple est de demander à votre hébergeur s'il l'a fait pour le serveur de votre site.
Dois-je faire quelque chose moi-même ?
Si votre site est sur un hébergement mutualisé, non : la mise à jour de PHP est faite par l'hébergeur. Il faut seulement vous assurer qu'elle a bien été faite. Si vous avez votre propre serveur, c'est à vous ou à votre prestataire d'installer les versions corrigées.
Mon site a-t-il pu être piraté ?
C'est possible : les premières tentatives ont eu lieu avant même la sortie du correctif. Un site exposé n'a pas forcément été attaqué pour autant. Des fichiers inconnus, des pages de spam dans Google ou des redirections vers d'autres sites sont des signes qui doivent alerter. Les premiers gestes si votre site a été piraté
Désactiver une fonction de PHP suffit-il ?
Non. Les réglages proposés en attendant le correctif réduisent le risque, mais l'équipe de PHP précise qu'ils ne rendent pas le serveur sûr. Seule la mise à jour de PHP corrige les deux failles.
Sources
- PHP : bulletins de sécurité du 20 au 26 octobre 2026 (nouvel onglet)
- CERT-FR : alerte CERTFR-2026-ALE-014 (nouvel onglet)
- NCSC (Royaume-Uni) : Critical security issue affecting PHP (nouvel onglet)
- Bulletin technique de la faille CVE-2026-109618 (nouvel onglet)
- Bulletin technique de la faille CVE-2026-109619 (nouvel onglet)
- Sansec : PHP2Shell, PHP RCE (nouvel onglet)
Faire le point sur votre site
Vous ne savez pas si le serveur de votre site a reçu le correctif ? Envoyez-moi son adresse : je vous dis ce qu'il faut demander à votre hébergeur. Réponse sous 24 heures ouvrées.
Appeler le 06 52 78 53 68