Faille PHP php2shell : votre site est-il concerné ?

Le 21 octobre 2026, l'équipe de PHP a publié en urgence des correctifs pour une faille PHP en deux volets, surnommée « php2shell ». PHP fait tourner environ 69 % des sites dont on connaît le langage serveur, dont tous les sites WordPress, Drupal, Joomla, Magento ou Laravel. Si le vôtre en fait partie, voici en clair ce qui se passe et ce qu'il faut faire.

Ce qui s'est passé

Le 20 octobre, des informations sur deux failles ont fuité avant la publication des correctifs. L'équipe de sécurité de PHP a aussitôt annoncé une mise à jour d'urgence pour le lendemain, et l'a publiée le 21 octobre : PHP 8.5.12, 8.4.27, 8.3.36 et 8.2.35 (annonce officielle sur php.net). Les attaques n'ont pas attendu : Amazon dit avoir repéré une première tentative d'exploitation dès le 17 octobre, quatre jours avant l'annonce publique, et Cloudflare voyait des attaques arriver le jour même de la publication (synthèse de Tenable).

Les deux failles, CVE-2026-109618 et CVE-2026-109619, sont notées 9,2 sur 10. Elles permettent à un attaquant d'exécuter son propre code sur le serveur, sans compte et sans mot de passe. Concrètement, quelqu'un qui réussit l'attaque peut lire votre base de données (clients, commandes, messages), installer une porte dérobée pour revenir plus tard, envoyer du spam depuis votre serveur ou rediriger vos visiteurs vers un autre site.

Votre site est-il concerné ?

Si votre site est fait avec WordPress, Drupal, Joomla, PrestaShop, Magento, Laravel ou Symfony, il tourne sous PHP. La question devient alors : quelle version de PHP, et a-t-elle été mise à jour ? Voici où en est chaque branche :

• PHP 8.2 à 8.5 : corrigé, à condition d'être passé en 8.2.35, 8.3.36, 8.4.27 ou 8.5.12.
• PHP 7.4 à 8.1 : plus de version officielle. L'équipe de PHP a publié des correctifs à compiler soi-même, et les a transmis en avance aux distributions Linux et aux fournisseurs de support étendu : votre hébergeur a pu les appliquer, il faut lui demander.
• PHP 5.4 à 7.3 : plus aucun correctif. Un serveur dans cette situation reste exposé tant qu'il n'est pas migré.

Pour connaître votre version : l'espace client de votre hébergeur l'affiche en général dans les réglages de l'hébergement. Sur WordPress, allez dans Outils, puis Santé du site, onglet Infos, rubrique Serveur. Regardez le numéro complet : « 8.3 » ne suffit pas, il faut au moins 8.3.36.

Que faire maintenant

1. 01Vérifiez la version exacte de PHP de chacun de vos sites, comme indiqué plus haut.
2. 02Sur un hébergement mutualisé, c'est l'hébergeur qui met PHP à jour. Contrôlez que la version affichée est bien corrigée, et écrivez à son support si ce n'est pas le cas.
3. 03Sur un serveur dédié ou un VPS, mettez PHP à jour puis redémarrez les services qui l'utilisent (PHP-FPM, Apache), sinon l'ancienne version continue de tourner en mémoire.
4. 04Si votre site tourne encore sous PHP 7 ou plus ancien, la mise à jour simple n'existe pas : il faut planifier la migration vers une version supportée, en vérifiant que le site et ses extensions la supportent.
5. 05Si le site est resté exposé ces derniers jours, cherchez des traces d'intrusion : fichiers PHP que vous ne connaissez pas, comptes administrateurs ajoutés, redirections bizarres, pics d'envoi d'e-mails. C'est ce que recommande le NCSC britannique.

« Il n'existe pas de protection complète : la mise à jour est la seule option sûre. »

C'est la consigne de l'équipe de sécurité de PHP elle-même. Des réglages temporaires existent pour réduire certains chemins d'attaque, mais elle précise qu'ils ne rendent pas une installation sûre. Si vous ne pouvez pas mettre à jour rapidement, le NCSC va jusqu'à conseiller de mettre le site hors ligne le temps de le corriger.

Le vrai sujet : un site, ça s'entretient

Une faille dans PHP, ça arrive. Ce qui fait la différence, c'est le temps de réaction. Un site suivi a été mis à jour dans les heures qui ont suivi la publication. Un site livré en 2019 et jamais touché depuis tourne probablement encore sous PHP 7, pour lequel il n'y a plus de version officielle. Son propriétaire ne le sait souvent pas, parce que le site s'affiche normalement. J'en parlais déjà dans Un site qu'on ne met jamais à jour : ce que vous risquez vraiment.

Un détail de cette affaire mérite qu'on s'y arrête : deux des équipes qui ont trouvé ces failles, Calif et Wiz, disent avoir utilisé des modèles d'IA dans leurs recherches. Les failles vont être trouvées plus vite, par les chercheurs comme par les attaquants. À mon avis, le rythme des correctifs ne va pas ralentir.

Ce que couvre une maintenance sérieuse

• Le suivi des alertes de sécurité : PHP, le CMS, les extensions, le serveur.
• Des mises à jour testées sur une copie du site avant d'être appliquées en ligne.
• Une version de PHP toujours dans une branche supportée, avec la migration planifiée avant la fin de support, pas après.
• Des sauvegardes automatiques, stockées ailleurs que sur le serveur, et qu'on a déjà essayé de restaurer.
• Une surveillance de la disponibilité et du certificat HTTPS, pour être prévenu avant vos clients.

Pour aller plus loin

• L'annonce de sécurité officielle (php.net) : les versions corrigées et les réglages temporaires, en anglais.
• L'alerte du NCSC : les actions prioritaires recommandées par l'agence britannique de cybersécurité.
• La FAQ de Tenable sur php2shell : la chronologie complète et le tableau des versions touchées.
• L'avis du CERT-EU : l'avis de sécurité européen sur les deux failles.

En résumé

Si votre site tourne sous PHP, vérifiez aujourd'hui sa version exacte et assurez-vous qu'elle est corrigée. C'est pour ce genre de semaine que la maintenance existe : quelqu'un surveille, applique le correctif et contrôle que tout fonctionne encore. Si vous ne savez pas qui s'occupe de votre site ni sur quelle version il tourne, envoyez-moi son adresse : je regarde et je vous dis s'il est exposé et ce qu'il faut faire.