Le 21 octobre 2026, l’équipe PHP a publié des correctifs contre deux vulnérabilités critiques, tandis qu’OpenAI détaillait la contribution de l’IA à leur découverte. Les autorités européennes demandent une action immédiate. Vous devez vérifier quels services sont concernés, qui les corrige et qui autorise leur maintien en ligne.

Selon OpenAI, Calif a identifié une faille critique de PHP avec GPT-5.6 Sol dans le cadre de Patch the Planet. Wiz a également découvert et signalé indépendamment les deux vulnérabilités concernées. Les responsables de PHP ont piloté les correctifs et leur publication.

Pour votre entreprise, la question immédiate concerne les logiciels qui font fonctionner vos services. Un portail documentaire connecté à un agent peut dépendre de PHP, même si vous achetez votre modèle d’IA auprès d’un autre fournisseur.

Cette semaine, une réponse commerciale affirmant que « tout est sécurisé » ne suffit pas. Demandez une preuve datée du traitement de ces vulnérabilités.

Ce qui est publié, et ce qui reste inconnu

PHP est un langage utilisé pour exécuter des sites et applications web. Son équipe indique que les vulnérabilités CVE-2026-109618 et CVE-2026-109619 peuvent permettre l’exécution de code à distance sans authentification : un attaquant pourrait faire exécuter des instructions au serveur sans disposer d’un compte.

Les versions correctives annoncées sont PHP 8.5.12, 8.4.27, 8.3.36 et 8.2.35. Certains distributeurs fournissent leurs propres paquets corrigés. Les protections temporaires ne constituent pas, selon PHP, une solution complète.

Dans leur déclaration commune du 21 octobre, les autorités européennes recommandent d’identifier les applications concernées, de coordonner les mises à jour avec les prestataires et de traiter prioritairement les systèmes accessibles depuis Internet. Si la correction immédiate est impossible, elles invitent à envisager leur isolement des réseaux publics.

Ces publications ne permettent pas de savoir si votre installation a été compromise. Une vulnérabilité établit une possibilité d’attaque ; elle ne prouve pas une intrusion. Une mise à jour ne suffit pas non plus à démontrer l’absence d’accès antérieur.

À Bordeaux, l’agent fonctionne mais son portail doit être vérifié

Prenons un exemple fictif : un cabinet de gestion patrimoniale de 25 salariés, à Bordeaux, dispose d’un portail client maintenu par une agence web. Un agent prépare des synthèses à partir des documents déposés sur ce portail.

Le fournisseur du modèle confirme que son service fonctionne normalement. L’agence indique que le portail utilise PHP, sans préciser immédiatement sa version ni son état de correction.

Le dirigeant doit décider si les dépôts restent ouverts pendant la vérification. Il doit aussi connaître les accès du portail : dossiers clients, stockage documentaire et éventuels identifiants permettant d’appeler le modèle.

La décision dépend donc de l’exposition du portail et des preuves fournies par son exploitant. Le bon fonctionnement de l’agent ne répond pas à cette question.

Les 6 preuves à demander cette semaine

Cette grille est une proposition de pilotage à appliquer avec vos équipes techniques et vos prestataires.

  1. Un inventaire des services concernés. Demandez la liste des sites, portails, interfaces et applications utilisant PHP, y compris chez les sous-traitants. Pour chaque service, faites identifier un responsable, son exposition à Internet et la version réellement utilisée. Incluez les outils auxquels vos agents accèdent.
  2. Une preuve du correctif installé. Exigez la référence de la mise à jour, sa date d’application et la vérification du logiciel effectivement en fonctionnement. Si le prestataire utilise un correctif adapté par son distributeur, demandez le bulletin correspondant. Un numéro de version isolé peut être insuffisant pour conclure.
  3. Une décision humaine sur le maintien en ligne. Pour chaque service encore exposé, faites consigner les mesures provisoires, leurs limites et le responsable de la décision. Fixez une heure de réexamen. Si une interruption est nécessaire, prévoyez un canal alternatif pour les clients et les équipes.
  4. Un examen des accès et des secrets. Identifiez ce qu’un serveur concerné peut atteindre : documents, bases de données, comptes techniques et clés d’accès aux modèles. Réduisez les droits inutiles. En présence d’indices de compromission, faites décider les révocations et renouvellements nécessaires par l’équipe chargée de l’incident.
  5. Un dossier de vérification conservé. Rassemblez les journaux disponibles, les horaires des interventions, les changements appliqués et les résultats des contrôles. Demandez explicitement si une recherche d’intrusion a été réalisée, sur quelle période et avec quelles limites. Distinguez « corrigé » de « vérifié après exposition ».
  6. Un engagement écrit sur les délais et les coûts. Faites préciser qui assure les corrections urgentes, sous quel délai et avec quelle validation. Vérifiez si l’intervention, l’analyse des journaux et la remise en service sont incluses dans la maintenance. Pour les agents interrompus, encadrez aussi les reprises automatiques afin d’éviter des traitements et consommations en double.

Ce que ça veut dire, vraiment

La découverte assistée par IA ne protège votre entreprise que lorsque le correctif atteint vos systèmes. Votre priorité est d’obtenir une chaîne de responsabilité vérifiable : un service identifié, un exploitant nommé, une correction prouvée et une décision documentée pour les exceptions. Demandez ces éléments aujourd’hui pour les services exposés, sans attendre la prochaine réunion de maintenance.

Sources