Le 21 octobre, le projet PHP a publié quatre versions corrigeant deux vulnérabilités critiques : PHP 8.5.12, 8.4.27, 8.3.36 et 8.2.35. Référencées CVE-2026-109618 et CVE-2026-109619 (CVE pour Common Vulnerabilities and Exposures), elles permettent à un attaquant non authentifié d'exécuter du code à distance sur les serveurs qui font tourner PHP depuis la version 5.4. PHP équipe près de 70 % des sites web selon W3Techs, cité par Cloudflare. Le correctif n'est pas une fin de crise : c'est le début de la course au déploiement.
Ce qui s'est passé, sans le communiqué
La découverte est revendiquée par OpenAI. Calif a identifié une faille avec GPT-5.6 Sol dans le cadre de Patch the Planet ; Wiz a trouvé et signalé les deux vulnérabilités indépendamment ; Quarkslab a participé à la coordination. Les mainteneurs de PHP ont mené les correctifs et la publication. OpenAI affirme que, « à sa connaissance », l'IA de frontière a trouvé ces failles avant les attaquants. C'est une affirmation invérifiable, et le genre de phrase qui se lit aussi comme un argument de positionnement.
Cloudflare apporte un détail plus opérationnel : la version corrigée a fuité avant la publication officielle, et l'entreprise dit avoir observé du trafic d'attaque visant ses clients. Les attaquants modifiaient leurs payloads pour contourner les règles, en suivant le volume de détections et en recoupant la logique du pare-feu. Cloudflare avait déployé ses protections WAF (web application firewall) avant la divulgation, y compris sur le plan gratuit. La défense a précédé l'annonce, pas l'inverse.
La découverte s'accélère. La décision de corriger, elle, reste humaine — et lente.
Le vrai signal : le délai entre correctif et exploitation
Le signal n'est pas le nombre de failles. C'est le décalage entre deux horloges. Côté mainteneurs, la correction a pris des mois : la PHP Foundation raconte qu'un problème identifié dès 2024 a mis des mois à être corrigé, entre désaccords et manque de ressources. Elle parle elle-même d'un « échec structurel ». Côté attaquants, la fenêtre se compte en heures : dès que le correctif fuite ou sort, les tentatives suivent.
Le 23 octobre, Cloudflare a signalé une vulnérabilité liée : CVE-2026-115560 touche les versions pourtant à jour, dont PHP 8.5.12, et ne sera corrigée qu'à la prochaine release. Les règles WAF couvrent le nom de champ par défaut du mécanisme de progression d'upload ; si vous l'avez personnalisé, vous n'êtes pas couvert. Voilà le genre de détail qui décide entre « patché » et « protégé ».
Le 20 octobre, Shopify a demandé aux développeurs d'applications d'agir « cette semaine » : scan de sécurité assisté par IA, jetons à expiration, filtrage des logs. Le message est explicite : les attaques augmentent à mesure que l'IA progresse. Un écosystème transforme la sécurité en prérequis de publication.
Ce que cela change dans un contrat de maintenance
Dans un contrat de maintenance, « mises à jour de sécurité incluses » ne veut plus dire grand-chose. Ce qui compte désormais tient en quatre lignes.
- Fenêtre de correctif : un délai maximal écrit pour les failles critiques, par exemple 24 à 72 heures entre la publication d'un correctif éditeur et sa mise en production, avec un responsable nommé.
- Périmètre : runtime PHP, dépendances, plugins, thème, hébergeur. Pour WordPress ou PrestaShop, la version de PHP est souvent contrôlée par l'hébergeur ; il faut savoir qui patche et sous quel délai.
- Veille : alertes CVE, avis éditeurs, règles WAF. Pas une revue annuelle déconnectée du déploiement.
- Preuve : version réellement déployée, date, journal, re-scan. Un ticket fermé n'est pas une preuve.
La dernière coûte le plus cher à mettre en place, et protège le mieux. Un client ne paie pas pour « de la sécurité » ; il paie pour savoir, à une date donnée, quelle version tourne et ce qui a été fait. C'est moins spectaculaire qu'un rapport de test d'intrusion, mais c'est vérifiable.
Ce que l'on risque de mal comprendre
Trois contresens guettent. Le premier : croire que l'IA remplace les mainteneurs. La faille PHP montre l'inverse. La découverte s'automatise, la décision de corriger reste humaine, collective, et lente. Le goulot n'est pas la détection, c'est l'arbitrage et le déploiement.
Le deuxième : confondre WAF et correctif. Cloudflare le dit elle-même : les protections sont une couche supplémentaire, il faut patcher. Un WAF achète du temps ; il ne supprime pas la cause. Le troisième : lire « 70 % des sites » comme « 70 % des sites vulnérables ». Le chiffre dit l'exposition potentielle, pas le nombre de victimes.
Qui gagne ? Les fournisseurs de sécurité et les plateformes qui peuvent pré-déployer des règles, parce qu'ils deviennent un point de passage obligé. Qui perd ? Les petites équipes qui héritent d'un parc PHP sans inventaire, et les prestataires qui vendaient une maintenance annuelle sans engagement de délai. Ce qui devient moins important : le rituel de l'audit annuel déconnecté du déploiement. Ce qui devient plus important : l'inventaire et la preuve.
Un WAF n'est pas un patch. C'est un délai d'achat — et personne ne sait combien de temps il achète.
Ce qu'il faut retenir
Faut-il tout réécrire ? Non. Faut-il changer de métier ? Pas encore. Mais la maintenance web cesse d'être une ligne budgétaire annuelle pour devenir un service avec des horaires. La faille est publiée le matin ; le correctif doit être dans la nuit. Cette phrase n'est pas une formule : c'est un cahier des charges.
Reste une incertitude honnête. On ne sait pas si la découverte assistée par IA va se stabiliser, ni si le volume d'exploitation suivra la même courbe. OpenAI annonce 1 milliard de dollars d'accès subventionnés à ses outils pour les défenseurs ; c'est un chiffre d'annonce, pas une mesure d'efficacité. Ce qui est déjà mesurable, c'est le raccourcissement du délai entre correctif et attaque. Pour un studio, la bonne réponse n'est pas un discours sur l'IA. C'est une clause, un inventaire, et une capture d'écran de la version déployée.