Le 21 octobre 2026, l'équipe de PHP a publié en urgence quatre versions correctives pour deux failles notées 9,2 sur 10. Surnommées PHP2Shell, ces failles PHP permettent à un attaquant non authentifié de prendre la main sur un serveur web. Or PHP fait tourner environ 70 % des sites dans le monde, dont tous les sites WordPress.
Sur le papier, la réponse est simple : on met à jour et on passe à autre chose. Dans la réalité, beaucoup de dirigeants découvrent cette semaine qu'ils ne savent pas qui est censé faire cette mise à jour sur leur site.
Cet article vous explique ce qui s'est passé, ce que vous devez vérifier cette semaine, et pourquoi cette alerte pose surtout une question de gouvernance : qui maintient vraiment votre site ? 👇🏼
La chronologie compte, parce qu'elle montre à quelle vitesse tout s'est enchaîné. Amazon a repéré une première tentative d'exploitation le 17 octobre sur ses serveurs pièges, quatre jours avant les correctifs. Le 20 octobre, les identifiants des failles (CVE-2026-109618 et CVE-2026-109619) ont fuité sur le forum Hacker News (Y Combinator). Le soir même, PHP a publié un préavis confirmant la sortie des correctifs pour le lendemain.
Les correctifs sont sortis le 21 octobre à 14 h UTC. Le même jour, Amazon écrivait que la faille était déjà « exploitée à grande échelle ». Au Royaume-Uni, le NCSC demande d'appliquer les mesures temporaires de PHP en attendant la mise à jour. Si elles sont impossibles ou trop longues à déployer, il conseille d'envisager la mise hors ligne. Aux Pays-Bas, plusieurs services publics ont été coupés par précaution.
D'habitude, une faille touche un plugin ou un thème. Cette fois, elle se loge dans PHP lui-même, le moteur qui exécute votre site. Selon l'avis officiel, toutes les installations qui répondent à des requêtes web sont à risque, quel que soit le mode de déploiement (PHP-FPM, Apache, LiteSpeed…).
Les chercheurs de Wiz ont démontré une prise de contrôle à distance sur les dernières versions de WordPress, Drupal et Joomla. Ils décrivent aussi une fuite de mémoire qui peut exposer des mots de passe, des jetons et des clés d'API. Patchstack résume la situation ainsi : un site WordPress est exposé quels que soient ses plugins s'il tourne sur une version vulnérable de PHP.
Les versions concernées remontent à PHP 5.4. Et seules les branches 8.2 à 8.5 reçoivent une vraie mise à jour. Pour 7.4, 8.0 et 8.1, PHP n'a publié que des correctifs de code source minimaux, et en dessous, il n'y a rien. Or, d'après des données de Mallory citées par The Hacker News, environ 884 000 serveurs exposés sur Internet affichent PHP 8.1 ou plus ancien. Cela représente 59 % de ceux qui indiquent leur version.
Pas besoin d'être technicien pour piloter ces vérifications. Il faut en revanche des réponses écrites, avec un nom en face de chaque ligne.
⚠️ Méfiez-vous des raccourcis. PHP indique que les réglages temporaires réduisent l'exposition mais ne rendent pas une installation sûre. Cloudflare présente ses règles de pare-feu comme une solution d'attente, et elles ne protègent que le trafic qui passe par Cloudflare. Patchstack déconseille aussi les plugins de « correctif » non officiels.
Si votre site est en PHP 8.2 ou plus, la mise à jour prend souvent quelques minutes à un hébergeur sérieux. En 8.1 ou moins, c'est une migration. Dans les deux cas, encore faut-il que quelqu'un s'en charge, et beaucoup de sites n'ont plus personne au bout du fil.
Le site a été livré il y a cinq ans par une agence qui ne le suit plus. L'hébergement mutualisé a été souscrit avec la carte du fondateur. Le freelance qui avait les accès est parti. Résultat : le jour où une alerte critique tombe, personne ne sait ni où regarder ni qui appeler. Rapid7 recommande de traiter cette mise à jour en urgence, en dehors des cycles habituels. Amazon va plus loin : pour les failles critiques exposées sur Internet, le délai de correction se compte en heures, pas en jours.
Exemple concret, une situation que l'on croise souvent : une PME industrielle avec un site vitrine WordPress en PHP 7.4, mis en ligne en 2020. Son formulaire de contact envoie les leads dans HubSpot grâce à un jeton d'application privée enregistré dans un plugin. Avec PHP2Shell, le site peut être défiguré, et le risque le plus grave est ailleurs : ce jeton peut fuiter et ouvrir l'accès à votre CRM, donc à vos contacts, vos transactions et vos historiques d'échanges.
En clair : votre site n'est pas un dossier clos depuis sa mise en ligne. C'est une porte d'entrée vers votre donnée commerciale.
Si votre entreprise fait tourner du PHP quelque part dans son écosystème, voici l'audit que nous recommandons de mener dès maintenant :
Ensuite vient une décision de fond. Si le site doit rester en PHP, il lui faut une maintenance sous contrat, avec quelqu'un d'identifié pour réagir sous quelques heures. Si le site n'a plus de propriétaire, nous recommandons souvent de le migrer vers un site sur HubSpot Content Hub. C'est un CMS hébergé : vous n'administrez aucun serveur PHP, et l'infrastructure est maintenue par l'éditeur. Cette option ne convient pas à tous les projets, et nous détaillons les critères dans notre comparatif headless CMS vs HubSpot CMS.
Pour les sites déjà sur HubSpot, la vigilance se déplace sur les intégrations : un connecteur maison hébergé sur un serveur PHP reste exposé. Notre checklist d'audit technique et notre accompagnement en intégration API et back-end couvrent justement ce point.
À la fin de cet audit, vous avez un inventaire écrit de vos sites et de leurs versions de PHP, la liste des jetons et clés à changer, et un responsable nommé pour chaque site. Vous voulez le mener avec nous ? Prenez rendez-vous avec notre équipe.
PHP2Shell est une faille PHP critique, déjà exploitée, qui touche presque toutes les versions en circulation. La mise à jour est la seule vraie protection, et les branches antérieures à 8.2 imposent une migration.
La leçon dépasse cette alerte. Un site sans responsable identifié est un risque pour votre image, mais aussi pour votre CRM et vos données clients.
Conseil if/else : notez dès aujourd'hui le nom de la personne qui met à jour chacun de vos sites. Si la case reste vide, vous avez votre priorité.
Vous ne savez pas qui maintient votre site ? Faisons le point ensemble.