Faille PHP du 21 octobre 2026 : que s’est-il passé ?

Le 21 octobre 2026, deux failles critiques de PHP, baptisées PHP2Shell, ont été rendues publiques avec leur correctif, et les tentatives d'attaque se sont comptées par millions dans les heures suivantes. Des préfectures, des sites ministériels et des services en ligne de plusieurs pays européens ont été coupés par précaution. Cette FAQ fait le point sur ce qui s'est passé, ce que Mirobolus a fait pour les sites sous contrat de maintenance, et comment vérifier vous-même que votre site est protégé.

Que s'est-il passé ?

Les failles ont été trouvées en août et devaient rester confidentielles jusqu'au jeudi 22 octobre, le temps de préparer le correctif. Une fuite le 20 octobre a obligé l'équipe PHP à avancer la publication d'un jour.

Point rassurant : à la date de rédaction de cet article, aucune intrusion réussie n'a été confirmée publiquement. Les coupures de sites étaient préventives. 

De quoi parle-t-on ?

Est-ce que ça touche d'autres domaines que les sites internet ?

Oui. PHP fait aussi tourner des applications métier, des portails clients et des logiciels en ligne. Le 21 et le 22 octobre, plusieurs services ont été suspendus par précaution :

• Administrations : préfectures, sites de Bercy et une partie du portail des impôts, site de vigilance de Météo-France ; portails publics aux Pays-Bas, en Finlande, en Belgique et en Allemagne.
• Logiciels en ligne : BambooHR, un logiciel RH, a coupé son service aux États-Unis, au Canada et en Irlande, interrompant la paie de ses clients.
• Banques, transports, télécoms : suspensions partielles de services numériques chez Nomura et Mitsubishi UFJ, ANA et East Japan Railway ; Orange a coupé l'accès à certains sites et applications dans plusieurs filiales.

Ces coupures montrent l'ampleur de la réaction, pas des piratages avérés : aucun de ces services n'a annoncé d'intrusion.

Qu'est-ce qui a été fait ?

Les autorités. En France, le CERT-FR a publié une alerte et le ministère de l'Intérieur a mis ses sites exposés en « maintenance préventive » à la demande de l'ANSSI. Au niveau européen, le CERT-EU a recommandé de mettre hors ligne les sites impossibles à corriger rapidement.

Les hébergeurs. La plupart ont appliqué le correctif dans les heures suivant sa sortie. Le soir du 21 octobre, OVHcloud annonçait ses hébergements web corrigés de PHP 7.4 à 8.5 ; d'autres déployaient version par version ou s'appuyaient sur des protections temporaires en attendant. Les hébergements mutualisés sous cPanel ont parfois reçu le correctif plus tard.

Les réseaux de diffusion. Cloudflare a activé un filtrage pour tous ses clients, y compris en offre gratuite, dès la nuit du 20 au 21 octobre. C'est une protection supplémentaire, pas un remplaçant du correctif.

Point d'attention : les versions PHP 8.1 et antérieures ne reçoivent plus de correctif officiel. Certains hébergeurs proposent un correctif adapté, mais la solution durable reste de passer à PHP 8.2 ou plus.

Qu'a fait Mirobolus pour les sites sous contrat ?

Tout au long de l'année. Un contrat de maintenance ne pouvait pas empêcher cette faille, mais il réduit ce qu'un attaquant peut obtenir. Sur les sites que je maintiens, WordPress, le thème et les extensions sont mis à jour régulièrement, la version de PHP est suivie et relevée quand elle n'est plus maintenue, et des sauvegardes sont réalisées automatiquement avec WP Umbrella.

Le 21 octobre. Dès l'annonce, j'ai :

1. lancé une sauvegarde immédiate de chaque site sous contrat, pour disposer d'une copie saine datée d'avant la vague d'attaques ;
2. surveillé les sites jusqu'à 23 h, avec le monitoring de WP Umbrella (disponibilité et alertes) ;
3. vérifié les versions PHP hébergeur par hébergeur pendant et après l'incident.

Sur les 34 sites actuellement sous contrat de maintenance, aucun incident n'a été constaté.

Comment vérifier que le correctif est appliqué sur votre site ?

Depuis votre tableau de bord WordPress, rendez-vous dans Outils > Santé du site, onglet Infos, puis ouvrez la rubrique Serveur. La ligne « Version de PHP » indique la version utilisée. Comparez-la au tableau ci-dessous.

Une nuance : certains hébergeurs appliquent le correctif sans changer le numéro affiché. Un numéro plus ancien ne signifie donc pas forcément que votre site est vulnérable, mais il mérite une question à votre hébergeur.