CVE PHP critique : couper le service plutôt que bricoler

Quand le projet PHP a annoncé qu'une version de sécurité critique arrivait, plusieurs jours avant que le correctif n'existe réellement, Internet a fait ce qu'il fait toujours : il a paniqué de manière productive. Les portails de connexion du gouvernement néerlandais, un diffuseur public et les sites du parlement ont été coupés préventivement. Cloudflare a remanié ses règles WAF en urgence. Les administrateurs systèmes échangeaient sur Reddit des contournements à moitié vérifiés dans php.ini pendant que des instructions d'exploitation circulaient sur les réseaux sociaux. Et voici mon avis à contre-courant, forgé en observant toute la séquence : les équipes qui ont tout simplement coupé leurs services ont pris la décision la plus intelligente de la salle, et celles qui concevaient des mitigations partielles astucieuses faisaient surtout du théâtre de la sécurité. Cette affirmation mérite d'être défendue, et elle a de vraies limites, alors voyons ce qu'une fenêtre de CVE PHP critique nous apprend réellement sur la stratégie de correctifs.

Pourquoi un correctif annoncé à l'avance est une arme à double tranchant

Le rythme habituel de divulgation d'une vulnérabilité est : correctif d'abord, détails ensuite. Cet incident a inversé la logique. Une vidéo qui a fuité a forcé la main de l'équipe PHP, et l'annonce est sortie avant le correctif, avec les versions corrigées (8.5.12, 8.4.27, 8.3.36, 8.2.35) programmées à une heure UTC fixe, quelques jours plus tard. Cet écart entre « nous confirmons qu'il existe quelque chose de critique » et « voici le correctif » est la période la plus dangereuse de la gestion moderne des vulnérabilités, car défenseurs et attaquants regardent désormais la même horloge.

Beaucoup de praticiens ont soutenu que le correctif aurait dû sortir immédiatement. Mais réfléchissons au mécanisme. Un correctif publié est, en pratique, un kit de rétro-ingénierie. Comparer le code source corrigé à la version précédente réduit le chemin de code vulnérable à quelques lignes, et avec la génération d'exploits assistée par LLM, le délai entre « diff disponible » et « exploit fonctionnel » est passé de plusieurs jours à quelques heures. Les responsables de release de PHP ont eux-mêmes admis avoir été stupéfaits de la rapidité avec laquelle un exploit est apparu avant même le correctif, une fois l'annonce ayant confirmé la classe de bug. Publier tôt ne coordonne pas le monde ; cela déclenche simplement le compte à rebours de l'attaquant pour des centaines de milliers d'instances non corrigées, pendant que ceux qui les exploitent dorment, sont en réunion ou bloqués dans des files de validation de changements.

L'heure fixe de publication, aussi gênante qu'elle paraisse, était en réalité le mécanisme de coordination. Tout le monde patche à 14 h UTC. Tous ceux qui sont fortement exposés coupent leurs services juste avant. Cette fenêtre synchronisée minimise à chaque instant le nombre total de serveurs vulnérables et en ligne. C'est la même logique que la divulgation coordonnée partout en sécurité : désordonnée, inconfortable, et généralement la moins mauvaise option.

Évaluer l'exploitabilité quand on dispose de presque aucune information

La partie la plus difficile de cette fenêtre a été le tri avec des données incomplètes. L'avis était volontairement vague, et pourtant il fallait décider : couper, atténuer ou attendre. Voici le cadre que j'utiliserais réellement, et il porte surtout sur la forme de votre exposition plutôt que sur la forme du bug.

• La surface d'attaque d'abord. Le premier signal visait la gestion des envois de fichiers et la progression des uploads de session. Si votre application accepte des requêtes POST multipart d'utilisateurs anonymes (formulaires de contact, envois d'avatars, outils d'import), vous êtes en tête de file. Un outil d'administration interne derrière VPN et SSO relève d'une classe de risque totalement différente.
• La portée de l'interpréteur. Un bug dans le cœur de PHP touche chaque version depuis une décennie, ce qui signifie que votre exposition correspond à peu près à « chaque processus PHP accessible par une requête ». L'inventaire compte davantage que l'analyse ici : la plupart des organisations ont découvert qu'elles faisaient tourner du PHP à des endroits oubliés, comme des micro-sites hérités, des tableaux de bord de supervision ou ce WordPress marketing de 2019.
• Le rayon d'impact. C'est là que les péchés architecturaux du passé se payent. Comme l'a résumé un praticien pendant la discussion, les applications PHP classiques tournent avec un rôle de base de données qui peut tout lire et tout écrire, partagé entre utilisateurs et administrateurs. Un processus PHP incontrôlé ne compromet pas seulement une application : il peut exfiltrer toute la base de données. Si votre application utilise des rôles par locataire et la sécurité au niveau des lignes, le pire scénario se réduit considérablement.
• La capacité de détection. Si vous ne pouvez pas répondre à la question « remarquerions-nous l'apparition d'un webshell sur cette machine ? », la rapidité de correction est votre seule défense. Cela touche à un angle mort plus large : la plupart des équipes journalisent les événements d'authentification, mais pas ce qui se passe après l'établissement de la session.

Passez ces quatre filtres et la décision se prend généralement toute seule. Exposition élevée, rayon d'impact large, pas de détection ? Coupez. Surface réduite, privilèges cloisonnés, bonne journalisation ? Vous pouvez probablement tenir jusqu'au correctif avec une règle WAF et une vigilance accrue.

Le piège des mitigations : pourquoi les correctifs partiels sous-performent le plus souvent

Quelques heures après l'annonce, une mitigation a circulé sur les forums : désactiver la progression des envois de session et les uploads de fichiers dans php.ini. Les gens l'ont configurée consciencieusement, vérifiée via phpinfo(), et se sont sentis rassurés. Puis un responsable de release PHP a affirmé sans détour que les seuls réglages INI ne vous protégeront pas : il faut patcher PHP. C'est le piège de la mitigation résumé en un échange. Les ajustements de configuration donnent une impression d'action, mais face à un bug de corruption mémoire dans l'interpréteur, ce sont des suppositions sur le chemin d'exploitation, pas une correction de la vulnérabilité.

La seule mitigation qui avait un réel impact était le filtrage de la forme des requêtes en périphérie. Si l'exploit nécessite des corps de requête multipart et que votre site n'a pas besoin d'envois de fichiers, bloquer carrément ce type de contenu supprime la voie d'attaque plutôt que d'espérer la gêner. Avec Apache, cela passe par une règle de réécriture :

# Block all multipart/form-data requests at the vhost level
RewriteEngine On
RewriteCond %{HTTP_CONTENT_TYPE} ^multipart/form-data [NC]
RewriteRule .* - [R=403,L]
# For nginx, the equivalent lives in the server block:
# if ($http_content_type ~* "^multipart/form-data") { return 403; }

Remarquez la logique conditionnelle, car c'est tout l'intérêt : cela fonctionne si les envois de fichiers ne sont pas une fonction critique. Si votre produit repose sur les uploads, vous venez de vous infliger un déni de service, ce qui est sans doute préférable à une exécution de code à distance, mais c'est une décision métier, pas de sécurité. Et cela reste un pari sur la forme de l'exploit : si un second vecteur apparaît (Cloudflare a indiqué mettre à jour ses mitigations à mesure que de nouveaux vecteurs se manifestaient), votre règle devient soudain obsolète. Le filtrage en périphérie achète du temps. Il n'achète pas la sécurité.

Le cas inconfortable en faveur de la coupure

Maintenant, l'affirmation par laquelle j'ai commencé. Un ingénieur de la discussion a pris la décision de mettre hors ligne toutes les applications de ses clients jusqu'à la sortie du correctif, puis a passé la journée au téléphone à s'expliquer. C'est professionnellement pénible. C'est aussi juste, et voici pourquoi : l'asymétrie des coûts est énorme. Quelques heures d'indisponibilité, c'est une mauvaise journée et une conversation gênante autour de la facture. Une RCE avant correctif sur un bug de l'interpréteur, avec des instructions d'exploitation qui circulent publiquement et des agents LLM capables de lancer des attaques à grande échelle, c'est une déclaration de fuite de données, une expertise forensique, et la question très réelle de devoir reconstruire chaque machine de zéro parce qu'on ne peut pas prouver qu'elle est saine.

Ce dernier point mérite d'être souligné. Plusieurs commentateurs ont estimé que la consigne rationnelle était « brûler les machines et tout recommencer », et ils n'exagéraient pas. Une post-exploitation sur un hôte PHP-FPM sans état partagé laisse encore des moyens de persistance : cron, fichiers modifiés, sessions empoisonnées, identifiants de base de données volés. Si vous étiez en ligne et non corrigé entre la publication de l'exploit et le correctif, « nous avons patché » ne répond pas à la question « ont-ils été compromis ? ». Une reconstruction à partir d'images saines, elle, le fait. Les équipes qui utilisaient une infrastructure immuable ont passé une semaine discrètement excellente : redéploiement sur une image de base corrigée, rotation des identifiants, et on passe à la suite.

Où l'argument de la coupure se fragilise-t-il ? En trois endroits. D'abord, les services réellement critiques (systèmes hospitaliers, flux de paiement, infrastructures d'urgence), où l'indisponibilité a son propre coût pour la sécurité : ceux-là demandent une isolation par couches, pas un interrupteur. Ensuite, les organisations dont la coupure prend plus de temps que la fenêtre de correctif ; si votre processus de release est une affaire manuelle de trois jours, vous n'alliez de toute façon pas battre 14 h UTC. Enfin, et c'est le plus humiliant : la coupure ne fonctionne que si vous savez tout ce que vous faites tourner. Le WordPress oublié sur un sous-domaine ne s'éteint pas parce que personne ne se souvient de son existence. L'inventaire des actifs, aussi peu glamour soit-il, constitue le véritable périmètre.

Mettre en place une stratégie de mise à jour de l'exécution avant la prochaine

Il y en aura une prochaine. La bonne question n'est pas comment vous vous êtes comportés pendant cette fenêtre, mais si la prochaine sera ennuyeuse. Quelques actions concrètes, par ordre de levier :

1. Suivre une version de PHP supportée et automatiser les mises à jour. Les équipes qui ont patché en quelques minutes étaient celles dont les images de base se reconstruisent et se redéploient à chaque tag. Si mettre à jour PHP signifie compiler sur un serveur artisanal, vous avez déjà perdu la course. Les paquets des distributions (Debian, Alpine) ont livré les versions corrigées dans les heures suivant la publication : suivre le rythme de sécurité de votre distribution bat les builds faits maison.
2. Placer un WAF avec règles managées devant tout ce qui est hérité. Cloudflare a atténué le problème grâce à ses règles WAF managées, sur les offres gratuites comme payantes, avant même que le correctif n'existe. On peut débattre de l'utilité réelle des WAF en général, entre profondeur de défense et théâtre ; dans une fenêtre pré-correctif, ce sont sans ambiguïté de la profondeur de défense.
3. Réduire dès maintenant le rayon d'impact sur la base de données. Rôles séparés pour la lecture et l'écriture, identifiants par application, et sécurité au niveau des lignes là où c'est pertinent. Le prochain bug d'interpréteur ne devrait pas signifier automatiquement une exfiltration complète de la base. C'est de l'ingénierie défensive au sens le plus pur : des systèmes qui se dégradent proprement quand une couche tombe.
4. S'entraîner au kill switch. Disposer d'une méthode documentée et testée pour basculer un service sur une page de maintenance statique en moins de quinze minutes. Le moment pour écrire ce runbook n'est pas pendant une fenêtre de divulgation.
5. Rendre les machines jetables. Images immuables, pas de serveurs artisanaux accessibles en SSH, rotation des identifiants en routine. Alors « brûler et reconstruire » devient un déploiement, pas une crise.

Une fenêtre de correctif annoncée à l'avance ne teste pas à quel point vos mitigations sont astucieuses. Elle teste la rapidité avec laquelle votre infrastructure, toute bête qu'elle soit, peut se mettre en mouvement.

Ce que cette fenêtre a réellement mesuré

Une fois le drame écarté, cet incident était un test de maturité opérationnelle, pas de PHP. L'interpréteur avait un bug ; les interpréteurs en ont. Ce qui a énormément varié, c'est le rayon d'impact et le temps de réaction à travers l'écosystème. Certaines équipes ont coupé net, patché au moment coordonné et reconstruit à partir d'images propres avant le déjeuner. D'autres ont passé la fenêtre à basculer des réglages INI en espérant que ça suffirait. La différence ne tenait pas à la sophistication en sécurité : elle tenait aux pipelines de déploiement, aux inventaires d'actifs, et à la volonté d'accepter une indisponibilité à court terme pour éviter une compromission à long terme.

Je maintiens donc mon affirmation d'ouverture, avec ses réserves : quand un bug critique et annoncé à l'avance dans l'interpréteur est à quelques heures d'être exploitable et que vos mitigations ne sont que des suppositions, débrancher est la décision responsable. Ce n'est pas satisfaisant. Ça ne fait pas bonne figure en démo. Mais la posture de sécurité ne se mesure pas au degré d'agitation pendant la crise : elle se mesure à votre capacité à prouver, après coup, que rien n'est entré. Si cette semaine vous ne pouvez pas répondre à cette question pour chaque processus PHP que vous faites tourner, c'est le vrai bug à corriger.