OpenAI : le modèle GPT‑5.6 Sol a trouvé une faille critique dans PHP, qui fait tourner 70% des sites

OpenAI a annoncé que son modèle GPT‑5.6 Sol avait trouvé un défaut critique dans PHP, l'un des langages de développement côté serveur les plus répandus. Selon l'entreprise, PHP fait tourner environ 70% des sites dans le monde. Ces deux derniers mois, OpenAI a dirigé une coalition de mainteneurs, de chercheurs et de fournisseurs de sécurité chargée de corriger les problèmes critiques du langage. L'article de blog a été publié il y a quelques heures, et des médias chinois, dont Jiqizhixin, présentent déjà l'incident comme l'une des vulnérabilités les plus marquantes de l'histoire du projet.

Deux mois de silence avant la publication

Cette annonce très médiatisée est l'aboutissement d'une longue préparation. Il y a deux mois, l'affaire n'a pas commencé par un communiqué de presse, mais par un canal de communication fermé entre OpenAI et les personnes responsables de la base de code de PHP. Ce schéma s'appelle la divulgation coordonnée : on signale d'abord la vulnérabilité discrètement aux mainteneurs, puis on prépare des correctifs pour les branches prises en charge et on prévient les grands fournisseurs d'hébergement et de sécurité. Ce n'est qu'ensuite qu'on en informe le public.

OpenAI ne s'est pas contentée de transmettre un rapport : elle a dirigé la coalition, ce qui distingue cette affaire des rapports de bugs habituels. L'entreprise a endossé le rôle d'organisatrice. Cette fonction revient d'ordinaire aux projets eux-mêmes, aux centres CERT ou à de grands éditeurs comme Google et Microsoft.

Pourquoi PHP

PHP est apparu au milieu des années 1990 et reste le socle d'une très large part du web : WordPress, Drupal, Magento, Laravel et d'innombrables sites d'entreprise reposent sur lui. Un défaut dans le langage lui-même ou dans ses composants standard ne touche pas un seul produit, mais toute la chaîne : du noyau aux plugins, en passant par les images d'hébergement et les conteneurs qui tournent en production depuis des années sans mise à jour.

C'est pourquoi le chiffre de 70% pèse ici plus lourd qu'une simple ligne dans la description d'une vulnérabilité. Même si l'exploitation exige certaines conditions, le nombre de serveurs potentiellement touchés se compte en millions. Et PHP a une particularité : de nombreuses installations tournent sur des versions obsolètes, qui ne reçoivent plus de correctifs depuis longtemps.

Le modèle en chasseur de bugs

Jusqu'ici, les exemples retentissants de recherche de vulnérabilités par IA concernaient des tâches ciblées : Google Big Sleep a trouvé une erreur dans SQLite, et lors de la compétition DARPA AIxCC, des équipes ont corrigé du code de façon automatique. Avec GPT‑5.6 Sol, la barre monte d'un cran : il s'agit d'un problème critique dans un runtime de base, surveillé par des milliers d'yeux, et d'une découverte qui a exigé une véritable opération de correction réunissant de multiples acteurs.

Pour l'industrie, c'est un signal à double sens. Les modèles offrent aux défenseurs la possibilité de passer au crible des projets matures plus vite que ne le font des équipes humaines. Mais les mêmes outils sont accessibles aux attaquants, et la fenêtre entre la publication d'un correctif et l'apparition d'exploits va donc se réduire.

Les paramètres clés de l'affaire :

• Modèle : GPT‑5.6 Sol
• Cible : PHP, langage de programmation open source
• Périmètre : environ 70% des sites dans le monde
• Durée de la coordination : environ deux mois
• Participants : mainteneurs, chercheurs, fournisseurs de sécurité
• Organisateur de la coalition : OpenAI

Que faire pour les équipes qui font tourner PHP en production

Premier point : l'inventaire. Il faut déterminer quelles versions de PHP tournent réellement sur les serveurs, dans les conteneurs et chez l'hébergeur, en particulier dans les projets oubliés et les vieux CMS. Deuxième point : suivre les versions de sécurité officielles de PHP ainsi que les listes de diffusion de sa distribution ou de son hébergeur. Quand les correctifs pour les branches prises en charge sortiront, mieux vaut mettre à jour rapidement : une fois le correctif publié, les attaquants savent où regarder.

Troisième point, qui concerne ceux qui restent sur des versions sorties du support. Pour eux, les correctifs pourraient ne pas sortir du tout ; mieux vaut donc lancer le plan de migration vers une branche à jour avant les premiers exploits, et non après. Enfin, il convient de vérifier que vous disposez d'une supervision des activités inhabituelles sur les serveurs web et d'un WAF capable d'activer rapidement des correctifs virtuels.

Pour ceux qui construisent les processus de sécurité, il y a aussi une leçon stratégique : l'audit de code open source par IA devient un outil de travail. Il est temps de lancer dès maintenant ce type de vérifications sur vos propres dépendances, avant que quelqu'un d'autre ne le fasse.