Les cinq étapes proposées par OpenAI pour divulguer les failles PHP

Le 21 octobre 2026, OpenAI a publié une proposition en cinq étapes pour coordonner la divulgation de deux failles critiques de PHP. PHP est un langage de programmation qui fait fonctionner des sites et des applications web côté serveur. La proposition décrit comment organiser la réparation et préparer les mises à jour avant de rendre les détails publics, mais OpenAI la présente comme un cadre à améliorer, pas comme une norme adoptée.

OpenAI indique que Calif a repéré une faille avec GPT-5.6 Sol et que Wiz a découvert indépendamment les deux vulnérabilités. Les mainteneurs de PHP ont dirigé les correctifs.

Les cinq étapes proposées par OpenAI

Le cadre suit la progression d’une faille détectée jusqu’au déploiement de son correctif. OpenAI en a détaillé les étapes dans sa proposition de divulgation coordonnée.

1. Valider et corriger la faille en amont. Les mainteneurs, les chercheurs et leurs partenaires techniques confirment l’impact, élaborent un correctif et le testent. OpenAI propose aussi de soumettre ce correctif à des modèles avancés pour chercher des contournements et des variantes de la faille.
2. Laisser aux organisations concernées le temps de se préparer. Les mainteneurs déterminent qui doit recevoir des informations à l’avance. Un distributeur peut adapter le correctif à une ancienne version, un hébergeur préparer une mesure de protection et un fournisseur de sécurité, une règle de pare-feu applicatif.
3. Coordonner les autorités publiques. Elles peuvent aider à faire parvenir les consignes aux organisations qui gèrent des infrastructures critiques et des services essentiels. Pour la réponse à PHP, OpenAI dit avoir mobilisé des partenaires gouvernementaux américains, dont la CISA et l’ONCD, ainsi que des partenaires internationaux.
4. Préparer les mises à jour en aval. Quand le correctif, les consignes et le calendrier de divulgation sont stabilisés, les mainteneurs peuvent associer d’autres distributeurs, hébergeurs, équipes de réponse et opérateurs afin de préparer les mises à jour et de repérer les lacunes de couverture.
5. Publier des consignes après la disponibilité du correctif. Les opérateurs peuvent alors évaluer leur exposition, trouver une mise à jour ou une mesure provisoire et vérifier que le logiciel corrigé fonctionne. Le déploiement se poursuit avec l’aide nécessaire aux organisations qui en ont besoin.

Quand le calendrier peut être réévalué

OpenAI propose de limiter les informations transmises à chaque participant à ce dont il a besoin pour protéger les systèmes concernés. Même des détails restreints peuvent révéler une vulnérabilité : le cadre prévoit donc de mettre en balance le risque de les partager et la protection que ce partage permet.

Les équipes réévalueraient le calendrier avec les mainteneurs en cas d’exploitation active, de fuite, de correctif public révélant la faille ou de remédiation bloquée qui accroît le risque pour les utilisateurs. OpenAI sollicite aussi des avis sur la durée des fenêtres de divulgation, les notifications par étapes, les garde-fous d’une éventuelle intervention d’urgence sur des systèmes autorisés et la préparation de correctifs pour d’anciennes versions. Ces choix restent des questions soumises à discussion dans sa proposition.

Les failles PHP et les versions corrigées

PHP décrit deux vulnérabilités d’exécution de code à distance sans authentification. Pour CVE-2026-109618, une erreur liée à un manque de mémoire peut interrompre le traitement d’une requête alors que des données internes ne sont pas entièrement initialisées. Le nettoyage qui suit peut alors traiter ces données invalides comme si elles étaient correctes.

CVE-2026-109619 concerne un état interne lié à une requête qui peut subsister après la libération de la mémoire associée. Une requête ultérieure traitée par le même processus de travail, ou « worker », peut réutiliser cet état avant sa réinitialisation. PHP attribue à chacune des deux failles un score de gravité CVSS v4.0 de 9,2.

PHP a publié les versions correctives suivantes :

Pour le contexte de publication, retrouvez aussi notre article sur les versions de PHP qui corrigent les deux failles.

PHP précise que les installations qui traitent des requêtes web peuvent être concernées, notamment avec PHP-FPM, Apache avec mod_php, php-cgi, FrankenPHP et LiteSpeed. Le projet juge le risque le plus élevé avec mod_php. PHP 8.1 et les branches antérieures ne reçoivent plus de mises à jour du projet, mais celui-ci a fourni des correctifs minimaux sous forme de code source pour PHP 7.4, 8.0 et 8.1. Certaines distributions et certains fournisseurs de support à long terme proposent également des correctifs rétroportés : les opérateurs de ces versions peuvent se renseigner auprès de leur fournisseur.

Les mesures provisoires réduisent certains risques, sans remplacer la mise à jour

PHP indique que seule une mise à jour apporte une correction complète. Ses mesures temporaires limitent certaines voies d’attaque, sans rendre une installation sûre.

Pour CVE-2026-109618, PHP recommande de régler memory_limit=-1, de préférence dans une configuration que les applications ne peuvent pas remplacer, et de limiter la taille des requêtes. Pour les sites sans téléversement de fichiers, l’avis propose post_max_size = 8M; si les téléversements sont nécessaires, il propose post_max_size = 32M et une valeur upload_max_filesize inférieure. PHP recommande aussi d’appliquer des limites adaptées au niveau du serveur web ou du proxy.

Pour CVE-2026-109619, PHP conseille de désactiver session.upload_progress.enabled avant l’analyse des requêtes, puis de redémarrer tous les workers. Ce réglage bloque les voies de session confirmées, mais pas les autres variantes. Sur PHP 8.5, fatal_error_backtraces=0 bloque uniquement la voie confirmée liée aux traces d’erreur fatale. Ces réglages ne remplacent pas l’installation d’une version corrigée.