Le 21 octobre 2026, le projet PHP a publié des correctifs d’urgence pour deux vulnérabilités critiques. PHP fait fonctionner une grande partie du web, y compris des sites WordPress, Drupal, Joomla ou Magento. Si votre site vitrine, votre boutique en ligne ou un outil interne repose sur ce langage, vous êtes potentiellement concerné, même si vous n’avez jamais vu une ligne de code. Cet article résume ce qui s’est passé, ce que cela implique pour votre entreprise et les gestes à faire dès maintenant, sans jargon inutile.
Ce qui s’est passé
Deux failles ont été identifiées sous les références CVE-2026-109618 et CVE-2026-109619. Toutes deux appartiennent à la catégorie la plus grave : l’exécution de code à distance. Concrètement, un attaquant qui parvient à exploiter une telle faille peut faire exécuter ses propres commandes par le serveur, depuis Internet. Selon le CERT-EU, chacune de ces failles obtient la note de 9,2 sur 10 sur l’échelle de gravité CVSS v4.0, ce qui les place dans le niveau critique.
La chronologie compte autant que la faille elle-même. Le lundi 20 octobre au matin, un message publié sur le forum Hacker News annonçait l’existence de deux vulnérabilités critiques de PHP. Le message a disparu rapidement, mais des captures d’écran ont circulé. Dans l’après-midi, les chercheurs en sécurité de watchTowr ont confirmé que les failles étaient réelles et ont reproduit la première. Une courte vidéo de démonstration a également été mise en ligne par erreur, puis retirée. Le soir, l’équipe de sécurité de PHP a avancé la publication des correctifs au mercredi 21 octobre à 14 h UTC, soit 16 h à Paris, car le secret initial n’était plus tenable.
Ce détail a une conséquence pratique : une fois qu’un correctif est public, les attaquants peuvent comparer l’ancien et le nouveau code pour comprendre où se situe le défaut. C’est pourquoi le temps de réaction compte beaucoup dans ce type d’épisode.
Les attaques ont-elles commencé ?
Au moment de la publication des correctifs, le tableau était contrasté. Selon The Hacker News, Cloudflare indiquait voir des attaques émerger avant même la sortie du correctif, et avait déployé des règles de protection par défaut sur son pare-feu applicatif. La société watchTowr, qui ne signalait aucune exploitation en début de journée le 21 octobre, faisait état dans l’après-midi de tentatives d’exploitation actives pour les deux failles. Le nombre de tentatives n’est pas précisé, et aucune compromission confirmée n’était rapportée à la date de cet article. Par précaution, certains services en ligne ont été interrompus temporairement, sans lien établi avec une intrusion.
En résumé : les tentatives existent, l’intrusion avérée dans votre entreprise n’est pas établie, mais le risque est réel et il augmente avec le temps qui passe tant que la mise à jour n’est pas faite.
Quelles versions de PHP sont touchées ?
Le projet PHP a publié quatre versions corrigées, une par branche encore maintenue :
| Branche PHP | Version corrigée |
| 8.5 | 8.5.12 |
| 8.4 | 8.4.27 |
| 8.3 | 8.3.36 |
| 8.2 | 8.2.35 |
Si votre site tourne sur une version antérieure à celles-ci au sein de ces branches, il est vulnérable. Le cas des anciennes versions mérite une attention particulière. Les branches PHP 8.1 et antérieures ne reçoivent plus de mises à jour du projet. Selon Sansec, les failles touchent les serveurs qui fonctionnent sous PHP 5.4 ou plus récent. Des correctifs sous forme de code source existent pour les versions 7.4, 8.0 et 8.1, mais il faut les compiler soi-même, ce qui reste hors de portée de la plupart des entreprises. Pour ces anciennes versions, la solution réaliste consiste à demander à votre hébergeur s’il applique un correctif adapté, ou à migrer vers une version maintenue.
Un point de vigilance : certains hébergeurs et distributions appliquent le correctif sans changer le numéro de version affiché. Le numéro ne suffit donc pas toujours à savoir si vous êtes protégé. Il faut une confirmation de l’hébergeur qui précise que les deux CVE sont bien corrigées.
Est-ce que mon site est concerné ?
Votre site est concerné s’il utilise PHP, ce qui est le cas de très nombreux sites professionnels. Les configurations citées par les sources comprennent PHP-FPM, Apache avec mod_php, php-cgi, FrankenPHP et LiteSpeed. Les mainteneurs jugent le risque particulièrement élevé avec mod_php.
Voici les situations les plus courantes pour une entreprise :
- Un site WordPress (vitrine, blog, boutique WooCommerce) : WordPress fonctionne avec PHP. Mettre à jour WordPress, ses thèmes et ses extensions ne remplace pas la mise à jour de PHP. Un site qui semble fonctionner normalement peut rester vulnérable.
- Une boutique en ligne sur Magento ou une autre solution PHP : la boutique manipule des données clients et des paiements, ce qui accroît l’enjeu. Sansec, spécialiste de la sécurité du commerce en ligne, a publié sa propre analyse de la faille.
- Un hébergement mutualisé : vous ne gérez pas PHP vous-même, c’est l’hébergeur qui doit déployer le correctif. Vous dépendez de son calendrier.
- Un serveur dédié ou un serveur privé virtuel : c’est à vous, ou à votre prestataire, d’appliquer la mise à jour et de redémarrer les services.
- Des applications internes développées sur mesure en PHP, parfois oubliées sur un serveur : pensez à les recenser.
Si votre site repose sur un autre langage, comme Python, Java ou Node.js, ces failles ne vous concernent pas directement. Demandez néanmoins à votre prestataire si d’autres composants de votre infrastructure utilisent PHP.
Les cinq actions à mener dès aujourd’hui
- Recensez ce qui utilise PHP. Listez vos sites, vos boutiques, vos outils internes et vos environnements de test. Chaque élément qui repose sur PHP doit être traité. Pour un serveur géré en interne, la commande php -v indique la version installée.
- Contrôlez la version. Sur un site WordPress, vous trouvez la version de PHP dans le menu « Outils », puis « Santé du site », onglet « Informations », rubrique « Serveur ». Confirmez ensuite avec votre hébergeur, car l’affichage ne détecte pas tous les cas de correctif appliqué sous un ancien numéro.
- Demandez une confirmation écrite à votre hébergeur ou prestataire. Elle doit préciser que les deux CVE sont corrigées sur tous vos environnements, la version ou la référence du paquet installé, la date de déploiement et le redémarrage des services. Un simple « c’est fait » à l’oral ne suffit pas, surtout si vous devez rendre des comptes à vos clients ou à votre assurance.
- Faites la mise à jour, avec une sauvegarde préalable. Sauvegardez avant toute migration, sans retarder la correction urgente. Après l’intervention, testez les fonctions essentielles : connexion, formulaires, panier et paiement, envoi d’e-mails, téléversement de fichiers. Un point d’attention technique : l’application des correctifs impose un redémarrage des services (Apache, PHP-FPM et processus associés), sans lequel la protection ne s’applique pas. Après la mise à jour, certains réglages de mémoire et de taille de requêtes méritent d’être relus, car la nouvelle limite plus stricte peut interrompre un processus.
- Cherchez des traces d’une éventuelle intrusion. Corriger la faille ne prouve pas qu’aucune attaque n’a eu lieu avant. Surveillez l’apparition de fichiers inconnus, de comptes administrateur que vous n’avez pas créés, de modifications inexpliquées ou de redirections étranges. Les journaux de votre serveur peuvent révéler des requêtes inhabituelles suivies d’erreurs répétées. Si quelque chose paraît suspect, faites appel à un prestataire de sécurité.
Et si la mise à jour est impossible immédiatement ?
Cette situation arrive : application ancienne incompatible avec une nouvelle version de PHP, prestataire injoignable, hébergeur qui n’a pas encore déployé le correctif. Dans ce cas, plusieurs mesures temporaires réduisent le risque, sans jamais remplacer la mise à jour.
Le CERT-EU recommande d’isoler les applications exposées sur Internet tant que le correctif n’est pas appliqué, ce qui peut aller jusqu’à les couper temporairement. Une simple page de maintenance WordPress ne suffit pas à cet isolement. Sansec évoque aussi, comme mesure provisoire, le blocage des requêtes de type « multipart/form-data » au niveau du serveur web, ce qui peut perturber certaines fonctions comme le téléversement de fichiers. Des réglages de configuration PHP circulent également, mais selon la développeuse du cœur de PHP Gina Peter Banyard, seule la mise à jour protège réellement. Un pare-feu applicatif, comme celui déployé par Cloudflare, apporte une couche de défense supplémentaire sans remplacer le correctif.
Si vous devez recourir à ces solutions de contournement, notez la date, la raison et la personne qui s’en charge, et fixez une échéance pour la vraie mise à jour.
Ce que cette affaire dit de la gestion de votre site
Au-delà de l’urgence, cet épisode met en lumière trois faiblesses courantes dans les entreprises.
La première concerne la responsabilité. Beaucoup de dirigeants ne savent pas qui gère PHP sur leur site : l’agence web, l’hébergeur, un ancien prestataire, un salarié parti. Clarifiez ce point par écrit. Un contrat de maintenance doit préciser qui applique les mises à jour de sécurité et sous quel délai.
La deuxième concerne les versions anciennes. Un site qui tourne sous une version de PHP qui n’est plus maintenue ne reçoit plus de correctifs officiels. Chaque nouvelle faille y devient un risque durable. Planifiez la migration plutôt que de la subir en urgence.
La troisième concerne la visibilité. Un inventaire à jour de vos sites et outils vous permet de réagir en quelques heures, pas en quelques jours. C’est un exercice simple, qui vaut la peine d’être fait une fois par an.
Ce qu’il faut communiquer à vos équipes et à vos clients
Si votre activité repose sur un site ou une boutique en ligne, informez votre équipe de la situation et désignez un responsable du suivi. Si vous traitez des données personnelles de clients, rappelez-vous que toute intrusion avérée peut déclencher des obligations de notification. En cas de doute, demandez l’avis de votre délégué à la protection des données ou d’un conseil juridique. Inutile d’alerter vos clients sans élément concret, mais préparez une information claire si une compromission est confirmée.
En résumé
Deux failles critiques de PHP, référencées CVE-2026-109618 et CVE-2026-109619, ont été corrigées le 21 octobre 2026 dans les versions 8.5.12, 8.4.27, 8.3.36 et 8.2.35. Des tentatives d’exploitation ont été signalées dès la publication des correctifs. Votre site est concerné s’il repose sur PHP, ce qui inclut la majorité des sites WordPress. Recensez vos sites, confirmez la version avec votre hébergeur par écrit, appliquez la mise à jour, redémarrez les services, puis surveillez les signes d’intrusion. Chaque jour de retard augmente le risque : c’est le bon moment de poser la question à votre prestataire.
