Le 21 octobre 2026, nous avons dû corriger en urgence deux failles critiques de PHP sur les serveurs que nous hébergeons et maintenons. Ce post-mortem retrace ce qui s’est passé, ce que nous avons fait, ce qui n’a pas fonctionné comme nous l’aurions voulu et ce qui reste à faire. L’intervention n’est pas terminée.
En bref
- Le correctif officiel de PHP a été appliqué sur les serveurs de production dès sa publication, vers 15 h 45, avec quelques minutes d’interruption par serveur.
- Des tentatives d’attaque ont été détectées en début d’après-midi, avant le correctif. D’après nos analyses à ce jour, elles n’ont pas abouti.
- Une partie de la faille semble rester exploitable malgré le correctif officiel. Les protections appliquées le matin restent en place et la surveillance continue.
- Nous avons identifié plusieurs points à améliorer, en premier lieu la façon de prendre les décisions urgentes avec nos clients.
Le contexte
Le 20 octobre, l’équipe de sécurité de PHP a annoncé deux failles critiques, CVE-2026-109618 et CVE-2026-109619, notées 9,2 sur 10 (CVSS v4). Elles permettent d’exécuter du code à distance sur un serveur, sans identifiant. Toutes les installations PHP qui servent des requêtes web sont concernées (PHP-FPM, mod_php, php-cgi), c’est-à-dire la grande majorité des sites Magento, WordPress, Symfony ou Drupal.
Dans ce genre de situation, les détails restent normalement confidentiels jusqu’à la sortie du correctif, pour laisser à chacun le temps de se préparer. Cette fois, des informations ont fuité avant la date prévue, et PHP a avancé la publication au 21 octobre, 16 h. Le risque d’attaques massives était élevé dès la publication : Matthew Prince, PDG de Cloudflare, a fait état de milliers de tentatives d’exploitation sur leur réseau dans les 10 heures qui ont précédé l’annonce, de dizaines de milliers dans les 45 minutes qui l’ont suivie et de millions depuis.
Chronologie du 21 octobre
- Matin : nous appliquons sur l’ensemble des environnements les premières mesures de protection qui circulent : désactivation de la fonctionnalité de PHP soupçonnée d’être en cause et règles de filtrage Cloudflare d’urgence pour les sites qui en bénéficient.
- De 13 h 45 à 14 h 51 : sur l’un des sites dont nous assurons l’infogérance, l’équipe d’administration système détecte des requêtes d’attaque liées à la faille. Sur 8 requêtes, 6 sont bloquées par la règle Cloudflare d’urgence ; 2 passent ce filtre et sont interrompues par l’attaquant lui-même. Tout indique à ce stade qu’aucune n’a abouti : la protection appliquée dans PHP le matin fait barrière.
- Début d’après-midi : nous écrivons à nos clients pour leur demander l’autorisation de mettre leur site en maintenance à titre préventif si nécessaire. Pour quelques clients critiques, nous renforçons les règles Cloudflare et proposons de couper les systèmes quelques minutes avant la publication du correctif. Les interventions prévues à 16 h sont avancées.
- Après-midi : nous arrêtons les environnements de développement et de préproduction, pour limiter le nombre de serveurs à traiter dans l’urgence, et préparons la mise à jour de chaque serveur de production.
- Vers 15 h 45 : le correctif sort avec environ un quart d’heure d’avance. Nous l’appliquons serveur par serveur, avec quelques minutes d’interruption à chaque fois. Comme il est arrivé avant l’heure prévue, il a été déployé plutôt que de couper les systèmes des clients critiques.
- Fin de journée : nous vérifions sur chaque serveur que la version corrigée est bien active.
Ce qui n’est pas terminé
- Selon les informations disponibles à ce jour, certaines failles persisteraient malgré le correctif : une version de PHP corrigée le 21 octobre resterait attaquable dans sa configuration par défaut. Les mesures du matin semblent y faire barrière, avec le filtrage Cloudflare ; nous les conservons.
- Les environnements de développement et de préproduction sont remis en service progressivement, et quelques interventions se poursuivent.
- La surveillance continue. Nous mettrons cet article à jour si la situation évolue.
Ce que nous devons améliorer
Décider plus vite avec nos clients
Demander l’autorisation de mettre un site en maintenance prend du temps, au moment précis où il en manque. Nous voulons convenir de ces décisions à l’avance, client par client.
Renforcer la sécurité de l’ensemble du système
Deux requêtes d’attaque ont passé le filtrage Cloudflare : la protection a tenu parce que plusieurs couches étaient en place, pas grâce à une seule. Des travaux de renforcement ont commencé sur l’ensemble de notre système d’information : environnements de développement, listes blanches d’accès, double authentification. Ils vont se poursuivre.
Réduire le nombre de versions anciennes
Les versions de PHP qui ne sont plus maintenues ont reçu des correctifs rétroportés, mais ce sont des rattrapages, sans garantie pour la prochaine faille. Une version maintenue reçoit un correctif en quelques minutes ; sur une version trop ancienne, il peut arriver plus tard, voire jamais, et la seule protection restante est parfois de couper le site.
Ce que cet épisode dit de la suite
Avec l’intelligence artificielle, les failles sont découvertes plus vite, mais elles sont aussi exploitées plus vite : le délai entre l’annonce d’une faille et les premières attaques massives se compte désormais en minutes, et non plus en jours. Le 21 octobre, plusieurs administrations européennes, dont les préfectures en France, ont préféré couper leurs sites par précaution. Garder ses systèmes à jour devient la condition pour pouvoir corriger à temps.
Pour les équipes techniques
- Failles : CVE-2026-109618 (corruption mémoire après un dépassement de mémoire) et CVE-2026-109619 (état interne réutilisé d’une requête à l’autre), CVSS v4 9,2, exécution de code à distance sans authentification.
- Versions corrigées : PHP 8.5.12, 8.4.27, 8.3.36 et 8.2.35. Pour les branches 7.x, 8.0 et 8.1, correctifs rétroportés par le mainteneur des paquets PHP que nous utilisons.
- Mesures transitoires, conservées après le correctif :
session.upload_progress.enabled = 0etsession.use_strict_mode = 1, règles de filtrage Cloudflare d’urgence, arrêt des environnements hors production. - Application du correctif : mise à jour des paquets, redémarrage complet des services web, contrôle qu’aucun processus ne tourne encore sur l’ancienne version. Mettre à jour le paquet ne suffit pas : PHP-FPM, Apache avec mod_php et les processus longs (files d’attente Magento, consommateurs de messages) gardent l’ancien code tant qu’ils ne sont pas redémarrés.
- Numéros de version : un correctif rétroporté ne change pas toujours le numéro de version de PHP. Un outil qui ne lit que ce numéro peut se tromper dans les deux sens ; seule la version du paquet installé fait foi.
Clients Sutunam : votre chef de projet reste disponible pour toute question sur vos serveurs.
Sources : avis de sécurité de PHP, 21 octobre 2026 ; Matthew Prince, Cloudflare ; SecurityWeek ; Reuters, via Global Banking & Finance.
